fixes#22909
required by https://github.com/nim-lang/Nim/pull/23267
```nim
proc foo: string =
assert false
result = ""
```
In the function `foo`, `assert false` raises an exception, which can
cause `result` to be uninitialized if the default result initialization
is optimized out
(cherry picked from commit 7d9721007c)
fixes#23247closes#23251 (which accounts for why the openarray type is lifted
because ops are lifted for openarray conversions)
related: https://github.com/nim-lang/Nim/pull/18713
It seems to me that openarray doesn't own the data, so it cannot destroy
itself. The same case should be applied to
https://github.com/nim-lang/Nim/issues/19435. It shouldn't be destroyed
even openarray can have a destructor. A cleanup will be followed for
https://github.com/nim-lang/Nim/pull/19723 if it makes sense.
According to https://github.com/nim-lang/Nim/pull/12073, it lifts
destructor for openarray when openarray is sunk into the function, when
means `sink openarray` owns the data and needs to destroy it. In other
cases, destructor shouldn't be lifted for `openarray` in the first place
and it shouldn't destroy the data if it doesn't own it.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
(cherry picked from commit 24a606902a)
fixes#17163, refs #23204
Types that aren't `tyRange` and are bigger than 16 bits, so `int32`,
`uint64`, `int` etc, are disallowed as array index range types.
`tyRange` is excluded because the max array size is backend independent
(except for the specific size of `high(uint64)` which crashes the
compiler) and so there should still be an escape hatch for people who
want bigger arrays.
(cherry picked from commit 3ab8b6b2cf)
fixes#23177
`changeType` doesn't perform range checks to see if the expression fits
the new type [if the old type is the same as the new
type](62d8ca4306/compiler/semexprs.nim (L633)).
For `nkIntLit`, we previously set the type to the concrete base of the
expected type first, then call `changeType`, which works for things like
range types but not bare types of smaller bit size like `int8`. Now we
don't set the type (so the type is nil), and `changeType` performs the
range check when the type is unset (nil).
(cherry picked from commit 00be8f287a)
fixes#22775
It's pre-existing that [`prepareOperand` doesn't typecheck expressions
which have
types](a4f3bf3742/compiler/sigmatch.nim (L2444)).
Templates can take typed subscript expressions, transform them into
calls to `[]`, and then have this `[]` not be resolved later if the
expression is nested inside of a call argument, which leaks an untyped
expression past semantic analysis. To prevent this, don't transform any
typed subscript expressions into calls to `[]` in templates. Ditto for
curly subscripts (with `{}`) and assignments to subscripts and curly
subscripts (with `[]=` and `{}=`).
(cherry picked from commit 62d8ca4306)
This code will crash `check`/`nimsuggest` since the `ra` register is
uninitialised
```nim
import macros
static:
discard parseExpr("'")
```
Now it assigns an empty node so that it has something
Testament changes were so I could properly write a test. It would pass
even with a segfault since it could find the error
(cherry picked from commit db9d8003b0)
Closes#14329
Marks `macros.error` as `.noreturn` so that it can be used in
expressions. This also fixes the issue that occurred in #19659 where a
stmt that could be an expression (Due to having `discardable` procs at
the end of other branches) would believe a `noreturn` proc is returning
the same type e.g.
```nim
proc bar(): int {.discardable.} = discard
if true: bar()
else: quit(0) # Says that quit is of type `int` and needs to be used/discarded except it actually has no return type
```
(cherry picked from commit b3b87f0f8a)
While looking at the CI I noticed that there's a couple false positives
for `case` statements that cannot be checked for exhaustiveness since my
changes, this should resolve them.
---------
Co-authored-by: SirOlaf <>
(cherry picked from commit 9140f8e221)
…tes invalid C identifiers
fixes#22913fixes#12985 differently
`{.push.} now does not apply to generic instantiations`
(cherry picked from commit 5dafcf4957)
In this PR, the following changes were made:
1. Replaced `raise newException(OSError, osErrorMsg(errno))` in batches
with `raiseOSError(errcode)`.
2. Replaced `newException(OSError, osErrorMsg(errno))` in batches with
`newOSError(errcode)`.
There are still some places that have not been replaced. After checking,
they are not system errors in the traditional sense.
```nim
proc dlclose(lib: LibHandle) =
raise newException(OSError, "dlclose not implemented on Nintendo Switch!")
```
```nim
if not fileExists(result) and not dirExists(result):
# consider using: `raiseOSError(osLastError(), result)`
raise newException(OSError, "file '" & result & "' does not exist")
```
```nim
proc paramStr*(i: int): string =
raise newException(OSError, "paramStr is not implemented on Genode")
```
(cherry picked from commit 39fbd30513)
Close#22826
I am not sure why this code skips generic insts, so letting CI tell me.
Update: It has told me nothing. Maybe someone knows during review.
Issue itself seems to be that the generic instance is skipped thus it
ends up being just `float` which makes it use the wrong generic instance
of the proc because it matches the one in cache
---------
Co-authored-by: SirOlaf <>
(cherry picked from commit c13c48500b)
The goal of this PR is to make `typeRel` accurate to it's definition for
generics:
```
# 3) When used with two type classes, it will check whether the types
# matching the first type class (aOrig) are a strict subset of the types matching
# the other (f). This allows us to compare the signatures of generic procs in
# order to give preferrence to the most specific one:
```
I don't want this PR to break any code, and I want to preserve all of
Nims current behaviors. I think that making this more accurate will help
serve as ground work for the future. It may not be possible to not break
anything but this is my attempt.
So that it is understood, this code was part of another PR (#22143) but
that problem statement only needed this change by extension. It's more
organized to split two problems into two PRs and this issue, being
non-breaking, should be a more immediate improvement.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
(cherry picked from commit b2ca6bedae)
`{.push overflowChecks: off.}` works in backends. Though it could be
implemented as a magic function.
By inspecting the generated C code, the overflow check is eliminated in
the debug or release mode.
Likewise, the index checking is probably not needed.
(cherry picked from commit d82bc0a29f)
Close#21742
Checking if there's any side-effects and if just changing typeRel is
adequate for this issue before trying to look into related ones.
`skipBoth` is also not that great, it can lead to code that works
sometimes but fails when the proc is instantiated with branching
aliases. This is mostly an issue with error clarity though.
---------
Co-authored-by: SirOlaf <unknown>
Co-authored-by: SirOlaf <>
(cherry picked from commit 2a8c759df0)
fixes#22639 for the third time
Nodes generated by `getType` for `tyGenericInst` types, instead of
having the original `tyGenericInst` type, will have the type of the last
child (due to the `mapTypeToAst` calls which set the type to the given
argument). This will cause subsequent `getType` calls to lose
information and think it's OK to use the sym of the instantiated type
rather than fully expand the generic instantiation.
To prevent this, update the type of the node from the `mapTypeToAst`
calls to the full generic instantiation type.
(cherry picked from commit ed9e3cba07)
fixes#22598, properly fixes#21887 and fixes test case issue number
When an enum field sym choice has to choose a type, check if its name is
ambiguous in the local scope, then check if the first symbol found in
the local scope is the first symbol in the sym choice. If so, choose
that symbol. Otherwise, give an ambiguous identifier error.
The dependence on the local scope implies this will always give
ambiguity errors for unpicked enum symchoices from generics and
templates and macros from other scopes. We can change `not
isAmbiguous(...) and foundSym == first` to `not (isAmbiguous(...) and
foundSym == first)` to make it so they never give ambiguity errors, and
always pick the first symbol in the symchoice. I can do this if this is
preferred, but no code from CI seems affected.
(cherry picked from commit 480e98c479)
