| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reverts #24184, reopens #12942, reopens #19118
#24184 seems to have caused a regression in
https://github.com/c-blake/thes and
https://github.com/c-blake/bu/blob/main/rp.nim#L84 reproducible with
`git clone https://github.com/c-blake/cligen; git clone
https://github.com/c-blake/thes; cd thes; nim c -p=../cligen thes`.
Changing the `const` to `let` makes it compile.
A minimization that is probably the same issue is:
```nim
const a: seq[string] = @[]
proc foo(x = a) =
echo typeof(x)
echo x
import macros
macro resemFoo() =
result = getImpl(bindSym"foo")
block:
resemFoo() # Error: cannot infer the type of parameter 'x'
```
This should be a regression test in a future reimplementation of #24184.
|
| |
|
|
|
|
| |
fixes #12942, fixes #19118
This is the exact same as #20735 but maybe the situation has improved
after #24065.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fixes #22276
When matching against `tyFromExpr`, the compiler tries to instantiate it
then operates on the potentially instantiated type. But the way it does
this is inverted, it checks if the instantiated type matches the
argument type, not if the argument type matches the instantiated type.
This has been the case since
https://github.com/nim-lang/Nim/commit/ac271e76b18110bea8046af64ceccd6b804978dd#diff-251afcd01d239369019495096c187998dd6695b6457528953237a7e4a10f7138,
which doesn't comment on it, so I'm guessing this isn't intended. I
don't know if it would break anything though.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #24121
Proc arguments can have typeclass type like `Foo | Bar` that `sigmatch`
handles specially before matching them to the param type, because they
wouldn't match otherwise. Not exactly sure why this existed but matching
any typeclass or unresolved type in generic contexts now fails the match
so typing the call is delayed until instantiation.
Also it turns out default values with `tyFromExpr` type depending on
other parameters was never tested, this also needs a patch to make the
`tyFromExpr` type `tfNonConstExpr` so it doesn't try to evaluate the
other parameter at compile time.
|
| |
|
|
|
| |
closes #4774, closes #7385, closes #10019, closes #12405, closes #12732,
closes #13270, closes #13799, closes #15247, closes #16128, closes
#16175, closes #16774, closes #17527, closes #20880, closes #21346
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #24099
If an arbitrary expression without a proc type (in this case
`tyFromExpr`) is called, the compiler [passes it to overload
resolution](https://github.com/nim-lang/Nim/blob/793cee4de1934fd1f6271cf5fed46f01c5abb19b/compiler/semexprs.nim#L1223).
But overload resolution also can't handle arbitrary expressions and
treats them as not participating at all, matching with the state
`csEmpty`. The compiler checks for this and gives an "identifier
expected" error. Instead, now if we are in a generic context and an
arbitrary expression call matched with `csEmpty`, we now return
`csNoMatch` so that `semResolvedCall` can leave it untyped as
appropriate.
The expression flag `efNoDiagnostics` is replaced with this check. It's
not checked anywhere else and the only place that uses it is
`handleCaseStmtMacro`. Replacing it with `efNoUndeclared`, we just get
`csEmpty` instead of `csNoMatch`, which is handled the same way here. So
`efNoDiagnostics` is now removed and `efNoUndeclared` is used instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes CI, refs #24066, refs #24065
The combination of #24065 and #24066 caused a CI failure where a `when`
branch that was never compiled gave an undeclared identifier error. This
is because the `when` branch was being semchecked with `semGenericStmt`
without `withinMixin`, which is the flag `semgnrc` normally gives to
`when` branch bodies. To fix this, just pass the whole `when` stmt to
`semGenericStmt` rather than the individual blocks.
The alternative would be to just replace the calls to `semGenericStmt`
with a new proc that does the same thing, just with the flags
`{withinMixin}`.
|
| |
|
|
|
|
|
|
| |
fixes #22342, fixes #22607
Another followup of #22029, `when` expressions in general in generic
type bodies now behave like `nkRecWhen` does since #24042, leaving them
as `tyFromExpr` if a condition is uncertain. The tests for the issues
were originally added but left disabled in #24005.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #16700, fixes #20916, refs #24010
Fixes the instantiation issues for proc param default values encountered
in #24010 by:
1. semchecking generic default param values with `inGenericContext` for
#22029 and followups to apply (the bigger change in semtypes),
2. rejecting explicit generic instantiations with unresolved generic
types inside `inGenericContext` (sigmatch change),
3. instantiating the default param values using `prepareNode` rather
than an insufficient manual method (the bigger change in seminst).
This had an important side effect of references to other parameters not
working since they would be resolved as a symbol belonging to the
uninstantiated original generic proc rather than the later instantiated
proc. There is a more radical way to fix this which is generating ident
nodes with `tyFromExpr` in specifically this context, but instead we
just count them as belonging to the same proc in
`hoistParamsUsedInDefault`.
Other minor bugfixes:
* To make the error message in t20883 make sense, we now give a "cannot
instantiate" error when trying to instantiate a proc generic param with
`tyFromExpr`.
* Object constructors as default param values generated default values
of private fields going through `evalConstExpr` more than once, but the
VM doesn't mark the object fields as `nfSkipFieldChecking` which gives a
"cannot access field" error. So the VM now marks object fields it
generates as `nfSkipFieldChecking`. Not sure if this affects VM
performance, don't see why it would.
* The nkRecWhen changes in #24042 didn't cover the case where all
conditions are constantly false correctly, this is fixed with a minor
change. This isn't needed for this PR now but I encountered it after
forgetting to `dec c.inGenericContext`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #16376
The way the compiler handled generic proc instantiations in calls (like
`foo[int](...)`) up to this point was to instantiate `foo[int]`, create
a symbol for the instantiated proc (or a symchoice for multiple procs
excluding ones with mismatching generic param counts), then perform
overload resolution on this symbol/symchoice. The exception to this was
when the called symbol was already a symchoice node, in which case it
wasn't instantiated and overloading was called directly ([these
lines](https://github.com/nim-lang/Nim/blob/b7b1313d21deb687adab2b4a162e716ba561a26b/compiler/semexprs.nim#L3366-L3371)).
This has several problems:
* Templates and macros can't create instantiated symbols, so they
couldn't participate in overloaded explicit generic instantiations,
causing the issue #16376.
* Every single proc that can be instantiated with the given generic
params is fully instantiated including the body. #9997 is about this but
isn't fixed here since the instantiation isn't in a call.
The way overload resolution handles explicit instantiations by itself is
also buggy:
* It doesn't check constraints.
* It allows only partially providing the generic parameters, which makes
sense for implicit generics, but can cause ambiguity in overloading.
Here is how this PR deals with these problems:
* Overload resolution now always handles explicit generic instantiations
in calls, in `initCandidate`, as long as the symbol resolves to a
routine symbol.
* Overload resolution now checks the generic params for constraints and
correct parameter count (ignoring implicit params). If these don't
match, the entire overload is considered as not matching and not
instantiated.
* Special error messages are added for mismatching/missing/extra generic
params. This is almost all of the diff in `semcall`.
* Procs with matching generic parameters now instantiate only the type
of the signature in overload resolution, not the proc itself, which also
works for templates and macros.
Unfortunately we can't entirely remove instantiations because overload
resolution can't handle some cases with uninstantiated types even though
it's resolved in the binding (see the last 2 blocks in
`texplicitgenerics`). There are also some instantiation issues with
default params that #24005 didn't fix but I didn't want this to become
the 3rd huge generics PR in a row so I didn't dive too deep into trying
to fix them. There is still a minor instantiation fix in `semtypinst`
though for subscripts in calls.
Additional changes:
* Overloading of `[]` wasn't documented properly, it somewhat is now
because we need to mention the limitation that it can't be done for
generic procs/types.
* Tests can now enable the new type mismatch errors with just
`-d:testsConciseTypeMismatch` in the command.
Package PRs:
- using fork for now:
[combparser](https://github.com/PMunch/combparser/pull/7) (partial
generic instantiation)
- merged: [cligen](https://github.com/c-blake/cligen/pull/233) (partial
generic instantiation but non-overloaded + template)
- merged: [neo](https://github.com/andreaferretti/neo/pull/56) (trying
to instantiate template with no generic param)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
closes #1969, closes #7547, closes #7737, closes #11838, closes #12283,
closes #12714, closes #12720, closes #14053, closes #16118, closes
#19670, closes #22645
I was going to wait on these but regression tests even for recent PRs
are turning out to be important in wide reaching PRs like #24010.
The other issues with the working label felt either finnicky (#7385,
#9156, #12732, #15247), excessive to test (#12405, #12424, #17527), or I
just don't know what fixed them/what the issue was (#16128: the PR link
gives a server error by Github, #12457, #12487).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#24005)
fixes #4228, fixes #4990, fixes #7006, fixes #7008, fixes #8406, fixes
#8551, fixes #11112, fixes #20027, fixes #22647, refs #23854 and #23855
(remaining issue fixed), refs #8545 (works properly now with
`cast[static[bool]]` changed to `cast[bool]`), refs #22342 and #22607
(disabled tests added), succeeds #23194
Parameter and return type nodes in generic procs now undergo the same
`inGenericContext` treatment that nodes in generic type bodies do. This
allows many of the fixes in #22029 and followups to also apply to
generic proc signatures. Like #23983 however this needs some more
compiler fixes, but this time mostly in `sigmatch` and type
instantiations.
1. `tryReadingGenericParam` no longer treats `tyCompositeTypeClass` like
a concrete type anymore, so expressions like `Foo.T` where `Foo` is a
generic type don't look for a parameter of `Foo` in non-generic code
anymore. It also doesn't generate `tyFromExpr` in non-generic code for
any generic LHS. This is to handle a very specific case in `asyncmacro`
which used `FutureVar.astToStr` where `FutureVar` is generic.
2. The `tryResolvingStaticExpr` call when matching `tyFromExpr` in
sigmatch now doesn't consider call nodes in general unresolved, only
nodes with `tyFromExpr` type, which is emitted on unresolved expressions
by increasing `c.inGenericContext`. `c.inGenericContext == 0` is also
now required to attempt instantiating `tyFromExpr`. So matching against
`tyFromExpr` in proc signatures works in general now, but I'm
speculating it depends on constant folding in `semExpr` for statics to
match against it properly.
3. `paramTypesMatch` now doesn't try to change nodes with `tyFromExpr`
type into `tyStatic` type when fitting to a static type, because it
doesn't need to, they'll be handled the same way (this was a workaround
in place of the static type instantiation changes, only one of the
fields in the #22647 test doesn't work with it).
4. `tyStatic` matching now uses `inferStaticParam` instead of just range
type matching, so `Foo[N div 2]` can infer `N` in the same way `array[N
div 2, int]` can. `inferStaticParam` also disabled itself if the
inferred static param type already had a node, but `makeStaticExpr`
generates static types with unresolved nodes, so we only disable it if
it also doesn't have a binding. This might not work very well but the
static type instantiation changes should really lower the amount of
cases where it's encountered.
5. Static types now undergo type instantiation. Previously the branch
for `tyStatic` in `semtypinst` was a no-op, now it acts similarly to
instantiating any other type with the following differences:
- Other types only need instantiation if `containsGenericType` is true,
static types also get instantiated if their value node isn't a literal
node. Ideally any value node that is "already evaluated" should be
ignored, but I'm not sure of a better way to check this, maybe if
`evalConstExpr` emitted a flag. This is purely for optimization though.
- After instantiation, `semConstExpr` is called on the value node if
`not cl.allowMetaTypes` and the type isn't literally a `static` type.
Then the type of the node is set to the base type of the static type to
deal with `semConstExpr` stripping abstract types.
We need to do this because calls like `foo(N)` where `N` is `static int`
and `foo`'s first parameter is just `int` do not generate `tyFromExpr`,
they are fully typed and so `makeStaticExpr` is called on them, giving a
static type with an unresolved node.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #21258
When a generic proc is instantiated, if one of the default values
doesn't match the type of the parameter, `seminst` sets the default
parameter node to an `nkEmpty` node with `tyError` type. `sigmatch`
checks for this to give an error message if the default param is
actually used, but only while actively matching the proc signature,
before the proc is even instantiated. The error message also gives very
little information.
Now, we check for this in `updateDefaultParams` at the end of
`semResolvedCall`, after the proc has been instantiated. The `nkEmpty`
node also is given the original mismatching type instead rather than
`tyError`, only setting `tyError` after erroring to prevent cascading
errors. The error message is changed to the standard type mismatch error
also giving the instantiation info of the routine.
|
| |
|
|
|
|
|
| |
Still have to look this over some. We'll see. I put sink in this branch
simply because I saw `tyVar` there and for no other reason. In any case
the problem appears to be coming from `liftParamType` as it removes the
`sink` type from the formals.
#23869
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
| |
closes https://github.com/nim-lang/RFCs/issues/480
|
| |
|
|
|
|
|
|
|
|
|
|
| |
* document general use of `_`, error message, fixes
fixes #20687, fixes #21435
Documentation and changelog updated to clarify new universal behavior
of `_`. Also new error message for attempting to use `_`, new tests,
and fixes with overloadable symbols and
implicit generics.
* add test for #21435
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parses the whole module at one time (#21379)
* fixes #19795; remove parse pipeline
* isScript
* fixes nimscriptapi
* don't touch reorder
* check script
* fixes tests
* it seems implicit imports of system cause troubles
* access the first child of `nkStmtList`
* ignore comments
* minor messages
* perhaps increases hloLoopDetector
* the module is a stmtList, which changes the errors
* fixes nimdoc
* fixes tlinter
* fixes nim secret tests
* fixes arc_misc
* fixes nim secret tests again
* safe; fixes one more test
* GlobalError is the root cause too
* fixes parsing errors
* put emit types to the cfsForwardTypes section
* fixes #11852; `{.push checks:off}` now works in procs
* disable navigator
* fixes nimdoc
* add tests for JS
* fixes nimsuggest
|
| |
|
|
|
|
|
|
|
| |
* underscores for routine parameters
fixes #13443, fixes #13804, refs #21121
* add changelog + more tests
* support generics and ensure inferred lambdas work
|
| |
|
|
|
|
|
|
|
| |
(#21065)
* fix #15836 proc arg return type auto unexpectly match proc with concrete type
* fix #16244
* add test case for #12869
|
| |
|
|
|
|
|
| |
concr…" (#21057)
Revert "fix #15836 proc arg return type auto unexpectly match proc with concr… (#21044)"
This reverts commit 0cd9bdcf9f6802421e0d8e4c28fc732012af605e.
|
| |
|
|
|
| |
(#21044)
fix #15836 proc arg return type auto unexpectly match proc with concrete type
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* manual: Document that comma propagates the default values of parameters
Fixes https://github.com/nim-lang/Nim/issues/15949.
* Use the "bug #NNNN" comment syntax for consistency
Ref:
https://nim-lang.github.io/Nim/contributing.html#writing-tests-stdlib
> Always refer to a GitHub issue using the following exact syntax: bug
for tooling.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
* Remove declPragmas from lambdas [backport:1.0]
* add test for exportc
* fix test
* fix align, nodecl -> noinit
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* fixes #10838
* reject func in types instead
* trigger tests
|
| |
|
|
| |
macros (#10275)
|
| |
|
|
|
|
| |
* proc does not take untyped/typed as argument
* Add TODO
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* merge magics
* merge metatype tests
* merge method tests
* merge objects tests
* change `import future` to `import sugar`
Nim in Action tests are left with `import future`, to ensure compatibility.
* merge overload tests
* merge proc tests
* merge procvar tests
* merge range tests
* merge seq tests
* merge sets tests
* remove wrong assert from `tsets3`
* fix `jsTests`
* better fix
|
| |
|
| |
Fixes #8357
|
| |
|
|
|
|
| |
The old implementation relied on the (now?) wrong assumption that
default-valued parameters can only be placed after the required ones.
Fixes #8683
|
| | |
|
| |
|
|
| |
via OSX: find . -name '*.nim' -exec sed -i '' -E 's/[[:space:]]+$//' {} +
|
| |
|