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)
* fixes#22613; Default value does not work with object's discriminator
fixes#22613
* merge branches
* add a test case
* fixes status
* remove outdated comments
* move collectBranchFields into the global scope
(cherry picked from commit affd3f7858)
* round out tuple unpacking assignment, support underscores
fixes#18710
* fix test messages
* use discard instead of continue
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
(cherry picked from commit 53d43e9671)
* Remove call-specific replaceTypeVarsN
* Run for all call kinds and ignore typedesc
* Testcase
---------
Co-authored-by: SirOlaf <>
(cherry picked from commit baf350493b)
* fix#12938 nim compiler assertion fail when literal integer is passed as template argument for array size
* use new flag tfImplicitStatic
* fix
* fix#14193
* correct tfUnresolved add condition
* clean test
(cherry picked from commit d53a89e453)
* Fix searchExtPos so that it returns -1 when the path is not a file ext
* fix comparision expression
* Remove splitDrive from searchExtPos
(cherry picked from commit db435a4a79)
* fix#20883 Unspecified generic on default value segfaults the compiler
* fallback to isGeneric
* change to closer error
* Update t20883.nim
(cherry picked from commit 26f183043f)
