fixes#23730
Since #23188 the compiler errors when matching a type variable to an
uninstantiated static value. However sometimes an uninstantiated static
value is given even when only a type match is being performed to the
base type of the static type, in the given issue this case is:
```nim
proc foo[T: SomeInteger](x: T): int = int(x)
proc bar(x: static int): array[foo(x), int] = discard
discard bar(123)
```
To deal with this issue we only error when matching against a type
variable constrained to `static`.
Not sure if the `q.typ.kind == tyGenericParam and
q.typ.genericConstraint == tyStatic` check is necessary, the code above
for deciding whether the variable becomes `skConst` doesn't use it.
fixes#23568, fixes#23310
In #23091 `semFinishOperands` was changed to not be called for `mArrGet`
and `mArrPut`, presumably in preparation for #23188 (not sure why it was
needed in #23091, maybe they got mixed together), since the compiler
handles these later and needs the first argument to not be completely
"typed" since brackets can serve as explicit generic instantiations in
which case the first argument would have to be an unresolved generic
proc (not accepted by `finishOperand`).
In this PR we just make it so `mArrGet` and `mArrPut` specifically skip
calling `finishOperand` on the first argument. This way the generic
arguments in the explicit instantiation get typed, but not the
unresolved generic proc.
fixes#23186
As explained in #23186, generics can transform `genericProc[int]` into a
call `` `[]`(genericProc, int) `` which causes a problem when
`genericProc` is resemmed, since it is not a resolved generic proc. `[]`
needs unresolved generic procs since `mArrGet` also handles explicit
generic instantiations, so delay the resolved generic proc check to
`semFinishOperands` which is intentionally not called for `mArrGet`.
The root issue for
[t6137](https://github.com/nim-lang/Nim/blob/devel/tests/generics/t6137.nim)
is also fixed (because this change breaks it otherwise), the compiler
doesn't consider the possibility that an assigned generic param can be
an unresolved static value (note the line `if t.kind == tyStatic: s.ast
= t.n` below the change in sigmatch), now it properly errors that it
couldn't instantiate it as it would for a type param. ~~The change in
semtypinst is just for symmetry with the code above it which also gives
a `cannot instantiate` error, it may or may not be necessary/correct.~~
Now removed, I don't think it was correct.
Still possible that this has unintended consequences.
refs #23091, especially post merge comments
Unsure if `experimental` and `bind` are the perfect constructs to use
but they seem to get the job done here. Symbol nodes do not get marked
`nfOpenSym` if the `bind` statement is used for their symbol, and
`nfOpenSym` nodes do not get replaced by new local symbols if the
experimental switch is not enabled in the local context (meaning it also
works with `push experimental`). However this incurs a warning as the
fact that the node is marked `nfOpenSym` means we did not `bind` it, so
we might want to do that or turn on the experimental switch if we didn't
intend to bind it.
The experimental switch name is arbitrary and could be changed.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
fixes#22605, separated from #22744
This marks symbol captures in macro calls in generic contexts as
`nfOpenSym`, which means if there is a new symbol in the local
instantiatied body during instantiation time, this symbol replaces the
captured symbol. We have to be careful not to consider symbols outside
of the instantiation body during instantiation, because this will leak
symbols from the instantiation context scope rather than the original
declaration scope. This is done by checking if the local context owner
(maybe should be the symbol of the proc currently getting instantiated
instead? not sure how to get this) is the same as or a parent owner of
the owner of the replacement candidate symbol.
This solution is distinct from the symchoice mechanisms which we
originally assumed had to be related, if this assumption was wrong it
would explain why this solution took so long to arrive at.
**TODO**
- [x] fixes changelog
With the new option `nimPreviewVtables`, `methods` are confined in the
same module where the type of the first parameter is defined
- [x] make it opt in after CI checks its feasibility
## In the following-up PRs
- [ ] in the following PRs, refactor code into a more efficient one
- [ ] cpp needs special treatments since it cannot embed array in light
of the preceding limits: ref
https://github.com/nim-lang/Nim/pull/20977#discussion_r1035528927; we
can support cpp backends with vtable implementations later on the
comprise that uses indirect vtable access
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
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 <>
fixes#22753
## Future work
We should turn all the error nodes into nodes of a nkError kind, which
could be a industrious task. But perhaps we can add a special treatment
for error nodes to make the transition smooth.
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 <>
Close#17509
Current knowledge:
- delaying cache fixes the issue
- changing return of `if inst.len < key.len:` in `searchInstTypes` to
`continue` fixes the issue. With return the broken types are also cached
over and over
Related issues are completely unaffected as of now, so there must be
something deeper.
I am also still trying to find the true cause, so feel free to ignore
for now
---------
Co-authored-by: SirOlaf <>
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.
fixes#22639
A `tyGenericInst` has its last son as the instantiated body of the
original generic type. However this type keeps its original `sym` field
from the original generic types, which means the sym's type is
uninstantiated. This causes problems in the implementation of `getType`,
where it uses the `sym` fields of types to represent them in AST, the
relevant example for the issue being
[here](d13aab50cf/compiler/vmdeps.nim (L191))
called from
[here](d13aab50cf/compiler/vmdeps.nim (L143)).
To fix this, create a new symbol from the original symbol for the
instantiated body during the creation of `tyGenericInst`s with the
appropriate type. Normally `replaceTypeVarsS` would be used for this,
but here it seems to cause some recursion issue (immediately gives an
error like "cannot instantiate HSlice[T, U]"), so we directly set the
symbol's type to the instantiated type.
Avoiding recursion means we also cannot use `replaceTypeVarsN` for the
symbol AST, and the symbol not having any AST crashes the implementation
of `getType` again
[here](d13aab50cf/compiler/vmdeps.nim (L167)),
so the symbol AST is set to the original generic type AST for now which
is what it was before anyway.
Not sure about this because not sure why the recursion issue is
happening, putting it at the end of the proc doesn't help either. Also
not sure if the `cl.owner != nil and s.owner != cl.owner` condition from
`replaceTypeVarsS` is relevant here. This might also break some code if
it depended on the original generic type symbol being given.
* test case haul for old generic/template/macro issues
closes#12582, closes#19552, closes#2465, closes#4596, closes#15246,
closes#12683, closes#7889, closes#4547, closes#12415, closes#2002,
closes#1771, closes#5121
The test for #5648 is also moved into its own test
from `types/tissues_types` due to not being joinable.
* fix template gensym test
* 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
* Play with typeRel
* Temp solution: Fixup call's param types
* Test result type with two generic params
* Asserts
* Tiny cleanup
* Skip sink
* Ignore proc
* Use changeType
* Remove conversion
* Remove last bits of conversion
* Flag
---------
Co-authored-by: SirOlaf <>
* Add test case
* Add in a bounds check when accessing generic types
Removes idnex out of bounds exception when comparing a generic that isn't fully instantiated
* Infer generic bindings
* Simple test
* Add t
* Allow it to work for templates too
* Fix some builds by putting bindings in a template
* Fix builtins
* Slightly more exotic seq test
* Test value-based generics using array
* Pass expectedType into buildBindings
* Put buildBindings into a proc
* Manual entry
* Remove leftover `
* Improve language used in the manual
* Experimental flag and fix basic constructors
* Tiny commend cleanup
* Move to experimental manual
* Use 'kind' so tuples continue to fail like before
* Explicitly disallow tuples
* Table test and document tuples
* Test type reduction
* Disable inferGenericTypes check for CI tests
* Remove tuple info in manual
* Always reduce types. Testing CI
* Fixes
* Ignore tyGenericInst
* Prevent binding already bound generic params
* tyUncheckedArray
* Few more types
* Update manual and check for flag again
* Update tests/generics/treturn_inference.nim
* var candidate, remove flag check again for CI
* Enable check once more
---------
Co-authored-by: SirOlaf <>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* sacrifice "tgenericshardcases" for working statics
* legacy switch for CI, maybe experimental later
* convert to experimental
* apparently untyped needs the experimental switch
* try special case call semcheck
* try fix
* fix compilation
* final cleanup, not experimental, make `when` work
* remove last needed use of untyped
* fix unused warning in test
* remove untyped feature
* 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
* always force open generic dot field symbols?
fixes#21724 but might break code
* alternative, should fix CI
* other alternative, add test for previous CI failure
* not needed
* make sure call doesn't compile too
* ok actual second test
* ok final actual correct test
* apply performance idea
* don't make fromDotExpr static
