fixes#25857
## Bug
`typeof(result)` inside the expression that builds `result` gets counted
as a read
of `result` before it's set. On a `{.requiresInit.}` return type that's
a hard error
("'result' requires explicit initialization"). `typeof` never evaluates
its operand,
so it's a false positive. On 2.2.4 it compiles, but the same line still
emits a bogus
`ProveInit` warning, so no released version gets it right.
Regression from #25151. That PR made a used-before-init `requiresInit`
result a hard
error instead of a warning, which is correct on its own. The side effect
was that
this old false-positive warning became a build error.
## Root cause
`track` in `compiler/sempass2.nim` has no arm for `nkTypeOfExpr`, so it
hits the
default that recurses into every child, reaches the `result` `nkSym`
inside the
`typeof`, and calls `useVar`. `sizeof`/`compiles`/`declared` don't hit
this because
they fold to a constant before `track` runs. A `typeof(result)` typedesc
argument
survives into `track`.
## Fix
Skip `nkTypeOfExpr` in `track`. Its operand is never evaluated, so it
isn't a
definite-assignment use. After the patch there's no error and no warning
here, even
with `--warnings:on`. The #25151 check is untouched: a real use of
`result` before
init is a plain `nkSym`, not inside a `typeof`, so it still reaches
`useVar`.
## Test
`tests/init/t25857.nim`, a positive test that compiles and prints `1`.
## Checks
- Repro compiles and runs on patched 2.2.6 and patched devel.
- `tests/errmsgs/t25117.nim` still fails as expected. A real
`xxx(result)` before
init still errors.
- `testament cat init` and `testament cat errmsgs` green on patched
devel (55 tests,
0 failures), including the `--warningAsError:ProveInit` tests.
- Bisect: parent `1ab68797` good, `576c4018` (#25151) bad.
```nim
{.experimental: "strictdefs".}
type Test = object
id: int
proc test(): Test =
if true:
return Test()
else:
return
echo test()
```
I will tackle https://github.com/nim-lang/Nim/issues/16735 and #21615 in
the following PR.
The old code just premises that in branches ended with returns, raise
statements etc. , all variables including the result variable are
initialized for that branch. It's true for noreturn statements. But it
is false for the result variable in a branch tailing with a return
statement, in which the result variable is not initialized. The solution
is not perfect for usages below branch statements with the result
variable uninitialized, but it should suffice for now, which gives a
proper warning.
It also fixes
```nim
{.experimental: "strictdefs".}
type Test = object
id: int
proc foo {.noreturn.} = discard
proc test9(x: bool): Test =
if x:
foo()
else:
foo()
```
which gives a warning, but shouldn't
* clean up some test categories
* mention exact slice issue
* magics into system
* move trangechecks into overflow
* move tmemory to system
* try fix CI
* try fix CI
* final CI fix
* fixes#21043; fixes a named exception in the infixAs expression which generate an implicit uninitialized let statement
* Update compiler/sempass2.nim
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* draft for let daa
* patch
* fixes bugs
* errors for global let variable reassignments
* checkpoint
* out param accepts let
* add more tests
* add documentation
* merge tests
* I don't care about observable stores
* enforce explicit initializations
* cleaner code for the stdlib
* stdlib: use explicit initializations
* make tests green
* algorithm.nim: set result explicitly
* remove out parameters and bring the PR into a mergable state
* updated the changelog
