| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
| |
The test case diff is self explanatory
|
| |
|
|
|
|
| |
Ref https://github.com/nim-lang/Nim/issues/23836#issuecomment-2233957324
Their types are basically equivalent so they should behave the same way
for type relations.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #19819, fixes #23339
Since #22029 `tyFromExpr` does not match anything in overloading, so
generic bodies can know which call expressions to delay until the type
can be evaluated. However generic type invocations also run overloading
to check for generic constraints even in generic bodies. To prevent them
from failing early from the overload not matching, pretend that
`tyFromExpr` matches. This mirrors the behavior of the compiler in more
basic cases like:
```nim
type
Foo[T: int] = object
x: T
Bar[T] = object
y: Foo[T]
```
Unfortunately this case doesn't respect the constraint (#21181, some
other bugs) but `tyFromExpr` should easily use the same principle when
it does.
|
| |
|
| |
#23823
|
| |
|
|
|
|
|
| |
#23755
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| | |
|
| |
|
| |
fixes #22409
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes an oversight with a change that I made a while ago.
Basically, these two snippets should both compile. Currently the
`varargs` version will fail.
```nim
template s(d: typed)=discard
proc something()=discard
proc something(x:int)=discard
s(something)
```
```nim
template s(d: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s(something)
```
Potentially unrelated, but this works currently for some reason:
```nim
template s(a: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s:
something
```
also, this works:
```nim
template s(b:untyped, a: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s (g: int):
something
```
but this doesn't, and the error message is not what I would expect:
```nim
template s(b:untyped, a: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s (g: int), something
```
So far as I can tell, none of these issues persist for me after the code
changes in this PR.
|
| |
|
| |
fixes #23249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #18125
Previously a tuple type like `(T, int)` would match an expected tuple
type `(U, int)` if `T` is a subtype of `U`. This is wrong since the
codegen does not handle type conversions of individual tuple elements in
a type conversion of an entire tuple. For this reason the compiler
already does not accept `(float, int)` for a matched type `(int, int)`,
however the code that checked for which relations are unacceptable
checked for `< isSubtype` rather than `<= isSubtype`, so subtypes were
not included in the unacceptable relations.
Update: Now only considered unacceptable when inheritance is used, as in
[`paramTypesMatch`](https://github.com/nim-lang/Nim/blob/3379d26629f30e6be8d303a36e220d1039eb4551/compiler/sigmatch.nim#L2252-L2254).
Ideally subtype relations that don't need conversions, like `nil`,
`seq[empty]`, `range[0..5]` etc would be their own relation
`isConcreteSubtype` (which would also allow us to differentiate with
`openArray[T]`), but this is too big of a refactor for now.
To compensate for this making things like `let x: (Parent, int) =
(Child(), 0)` not compile (they would crash codegen before anyway but
should still work in principle), type inference for tuple constructors
is updated such that they call `fitNode` on the fields and their
expected types, so a type conversion is generated for the individual
subtype element.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23200, fixes #18866
#21065 made it so `auto` proc return types remained as `tyAnything` and
not turned to `tyUntyped`. This had the side effect that anything
previously bound to `tyAnything` in the proc type match was then bound
to the proc return type, which is wrong since we don't know the proc
return type even if we know the expected parameter types (`tyUntyped`
also [does not care about its previous bindings in
`typeRel`](https://github.com/nim-lang/Nim/blob/ab4278d2179639f19967431a7aa1be858046f7a7/compiler/sigmatch.nim#L1059-L1061)
maybe for this reason).
Now we mark `tyAnything` return types for routines as `tfRetType` [as
done for other meta return
types](https://github.com/nim-lang/Nim/blob/18b5fb256d4647efa6a64df451d37129d36e96f3/compiler/semtypes.nim#L1451),
and ignore bindings to `tyAnything` + `tfRetType` types in `semtypinst`.
On top of this, we reset the type relation in `paramTypesMatch` only
after creating the instantiation (instead of trusting
`isInferred`/`isInferredConvertible` before creating the instantiation),
using the same mechanism that `isBothMetaConvertible` uses.
This fixes the issues as well as making the disabled t15386_2 test
introduced in #21065 work. As seen in the changes for the other tests,
the error messages give an obscure `proc (a: GenericParam): auto` now,
but it does give the correct error that the overload doesn't match
instead of matching the overload pre-emptively and expecting a specific
return type.
tsugar had to be changed due to #16906, which is the problem where
`void` is not inferred in the case where `result` was never touched.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
statics (#23188)
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.
|
| |
|
| |
#23172
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is in reference to a [feature
request](https://github.com/nim-lang/Nim/issues/22142) that I posted.
I'm making this PR to demonstrate the suggested change and expect that
this should be scrutinized
---------
Co-authored-by: Bung <crc32@qq.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23002, fixes #22841, refs comments in #23097
When an identifier is ambiguous in scope (i.e. multiple imports contain
symbols with the same name), attempt resolving it through type inference
(by creating a symchoice). To do this efficiently, `qualifiedLookUp` had
to be broken up so that `semExpr` can access the ambiguous candidates
directly (now obtained directly via `lookUpCandidates`).
This fixes the linked issues, but an example like:
```nim
let on = 123
{.warning[ProveInit]: on.}
```
will still fail, since `on` is unambiguously the local `let` symbol here
(this is also true for `proc on` but `proc` symbols generate symchoices
anyway).
Type symbols are not considered to not confuse the type inference. This
includes the change in sigmatch, up to this point symchoices with
nonoverloadable symbols could be created, they just wouldn't be
considered during disambiguation. Now every proper symbol except types
are considered in disambiguation, so the correct symbols must be picked
during the creation of the symchoice node. I remember there being a
violating case of this in the compiler, but this was very likely fixed
by excluding type symbols as CI seems to have found no issues.
The pure enum ambiguity test was disabled because ambiguous pure enums
now behave like overloadable enums with this behavior, so we get a
longer error message for `echo amb` like `type mismatch: got <MyEnum |
OtherEnum> but expected T`
|
| |
|
|
|
|
|
|
|
|
| |
Filling in some more logic in `typeRel` that I came across when poking
the compiler in another PR. Some of the cases where `typeRel` returns an
"incorrect" result are actually common, but `sumGeneric` ends up
breaking the tie correctly. There isn't anything wrong with that
necessarily, but I assume that it's preferred these functions behave
just as well in isolation as they do when integrated.
I will be following up this description with specific examples.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
#23032
---------
Co-authored-by: Nikolay Nikolov <nickysn@gmail.com>
Co-authored-by: Pylgos <43234674+Pylgos@users.noreply.github.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Co-authored-by: Jason Beetham <beefers331@gmail.com>
|
| |
|
|
|
| |
(#23063)
… type mirroring proc params
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just makes the case statements easier to look at when folded
```nim
case foo
of a:
of b:
of c:
else:
case bar:
of a:
of b:
of c:
of d:
else:
```
to
```nim
case foo
of a:
of b:
of c:
else:
case bar:
of a:
of b:
of c:
of d:
else:
```
|
| | |
|
| | |
|
| |
|
| |
follow up https://github.com/nim-lang/Nim/pull/22851
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
| |
fixes #10542
revives and close #20169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <>
|
| |
|
|
|
|
|
| |
reverts #22642, reopens #22639, closes #22646, refs #22650, refs
https://github.com/alaviss/union/issues/51, refs #22652
The fallout is too much from #22642, we can come back to it if we can
account for all the affected code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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](https://github.com/nim-lang/Nim/blob/d13aab50cf465a7f2edf9c37a4fa30e128892e72/compiler/vmdeps.nim#L191)
called from
[here](https://github.com/nim-lang/Nim/blob/d13aab50cf465a7f2edf9c37a4fa30e128892e72/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](https://github.com/nim-lang/Nim/blob/d13aab50cf465a7f2edf9c37a4fa30e128892e72/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.
|
| |
|
|
|
|
|
|
|
| |
* `initCandidate` and friends now return values
* fixes semexprs.nim
* fixes semcall.nim
* Update compiler/semcall.nim
|
| |
|
|
|
| |
* Markdown code blocks migration part 9
* fix [skip ci]
|
| |
|
|
|
|
|
|
|
|
|
| |
* unpublic the sons field of PType
* tiny fixes
* fixes an omittance
* fixes IC
* fixes
|
| | |
|
| |
|
| |
* fix #5780
|
| |
|
|
|
| |
(#20683)
* fix #18823 Passing Natural to bitops.BitsRange[T] parameter in generic proc is compile error
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* wip; use strictdefs for compiler
* checkpoint
* complete the chores
* more fixes
* first phase cleanup
* Update compiler/bitsets.nim
* cleanup
|
| |
|
|
|
|
|
|
|
| |
* fix #20883 Unspecified generic on default value segfaults the compiler
* fallback to isGeneric
* change to closer error
* Update t20883.nim
|
| |
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
| |
* Expands codegenDecl to work in function params. fixes #22306
* makes the test more concrete so T{lit} params dont match
* adds sfCodegenDecl
|
| | |
|
| |
|
| |
fixes #22187
|
| |
|
|
|
|
|
|
|
|
|
| |
* fix `var object` not matching better than `object`
fixes #13302
* remove comment for brevity
* try note
* try minimize breaks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* fixes #22054; codegen for var tuples conv
* rethink fixes
* add test cases
* templates only
* fixes var tuples
* keep varness no matter what
* fixes typ.isNil
* make it work for generics
* restore isSubrange
* add a test case as requested
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* test `proc` not converting to `pointer`
* ignore define for now to test
* remove cstring
* fixes, changelog
|
| |
|
|
|
|
|
|
|
|
|
| |
(#21667)
* refactoring in preparation for better, simpler name mangling that works with IC flawlessly
* use new disamb field
* see if this makes tests green
* make tests green again
|