| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
iterators (#23986)
fixes #23982
|
| |
|
|
| |
fixes #23973;
fixes #23974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #8697, fixes #9620, fixes #23265
When matching a `template` with an `untyped` argument fails because of a
mismatching typed argument, `presentFailedCandidates` tries to sem every
single argument to show their types, but trying to type the `untyped`
argument can fail if it's supposed to use an injected symbol, so we get
an unrelated error message like "undeclared identifier".
Instead we use `tryExpr` as the comment suggests, setting the type to
`untyped` if it fails to compile. We could also maybe check if an
`untyped` argument is expected in its place and not try to compile the
expression if it is but this would require a bit of reorganizing the
code here and IMO it's better to have the information of what type it
would be if it can be typed.
|
| |
|
| |
Noticed Hint [Pattern] spam in CI
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23977
The problem is that for *any* body of a generic declaration,
[semstmts](https://github.com/nim-lang/Nim/blob/2e4d344b43b040a4dce2c478ca13e49979e491fc/compiler/semstmts.nim#L1610-L1611)
sets the sym of its value to the generic type name, and
[semtypes](https://github.com/nim-lang/Nim/blob/2e4d344b43b040a4dce2c478ca13e49979e491fc/compiler/semtypes.nim#L2143)
just directly gives the referenced type *specifically* when the
expression is a generic body. I'm blaming `semtypes` here because it's
responsible for the type given but the exact opposite behavior
specifically written in makes me think generating an alias type here
maybe breaks something.
|
| |
|
|
| |
(#23964)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #10753, fixes #22021, refs #19365 (was fixed by #22029, but more
faithful test added)
For whatever reason `compileTime` proc calls did not fold if the proc
was generic ([since this folding was
introduced](https://github.com/nim-lang/Nim/commit/c25ffbf2622a197c15a4a3bd790b1bc788db2c7f#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40)).
I'm guessing the intention was for *unresolved* generic procs to not
fold, which is now the logic.
Non-magic `compileTime` procs also now don't fold at compile time in
`typeof` contexts to avoid possible runtime errors (only the important)
and prevent double/needless evaluation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23689
Normally pure enum symbols only "exist" in lookup if nothing else with
the same name is in scope. But if an expression is expected to be an
enum type, we know that ambiguity can be resolved between different
symbols based on their type, so we can include the normally inaccessible
pure enum fields in the ambiguity resolution in the case that the
expected enum type is actually a pure enum. This handles the use case in
the issue of the type inference for enums reverted in #23588.
I know pure enums are supposed to be on their way out so this might seem
excessive, but the `pure` pragma can't be removed in the code in the
issue due to a redefinition error, they have to be separated into
different modules. Normal enums can still resolve the ambiguity here
though. I always think about making a list of all the remaining use
cases for pure enums and I always forget.
Will close #23694 if CI passes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#23154)
Before (devel)
After (this PR and stable)
It now keeps the same behavior as before
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
fixes #22850
The `is` operator checks the type of the left hand side, and if it's
generic or if it's a `typedesc` type with no base type, it leaves it to
be evaluated later. But `typedesc` types with no base type precisely
describe the default typeclass `type`/`typeclass`, so this condition is
removed. Maybe at some point this represented an unresolved generic
type?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #22571
Removes the hack added in #13589 which made non-top-level object type
symbols `gensym` because they couldn't be mangled into different names
for codegen vs. top-level types. Now we consider the new `disamb` field
(added in #21667) of the type symbols in the type hash (which is used
for the mangled name) to differentiate between the types.
In other parts of the compiler, specifically the [proc
mangling](https://github.com/nim-lang/Nim/blob/298ada3412c9cf5971abc2b3b891b9bb8612e170/compiler/mangleutils.nim#L59),
`itemId.item` is used instead of the `disamb` field, but I didn't use it
in case it's the outdated method.
|
| |
|
| |
fixes #23954
|
| |
|
|
|
| |
`nimPreviewRangeDefault` (#23950)
ref https://github.com/nim-lang/Nim/issues/23943
|
| |
|
| |
fixes #23947
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
refs https://github.com/nim-lang/Nim/pull/23873#discussion_r1687995060,
fixes #23386, fixes #23385, supersedes #23572
Turns the `nfOpenSym` node flag implemented in #23091 and extended in
#23102 and #23873, into a node kind `nkOpenSym` that forms a unary node
containing either `nkSym` or `nkOpenSymChoice`. Since this affects
macros working on generic proc AST, the node kind is now only generated
when the experimental switch `genericsOpenSym` is enabled, and a new
node flag `nfDisabledOpenSym` is set to the `nkSym` or `nkOpenSymChoice`
when the switch is not enabled so that we can give a warning.
Now that the experimental switch has more reasonable semantics, we
define `nimHasGenericsOpenSym2`.
|
| |
|
|
|
|
|
|
| |
(#23933)
…s enabled at compile time.
#8644 This doesn't handle the case if `{.push experimental.}` is used,
but at least we can test if a feature was enabled globally.
|
| |
|
|
|
|
| |
[backport] (#23941)
fixes #23936
follow up https://github.com/nim-lang/Nim/pull/20527
|
| |
|
| |
fixes jsbigint64 regression
|
| |
|
|
| |
fixes #23932
ref https://github.com/jmgomez/NimForUE/issues/36
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
actually fixes #23865 following up #23873
In the handling of `nkIdent` in `semExpr`, the compiler looks for the
closest symbol with the name and [checks the symbol
kind](https://github.com/nim-lang/Nim/blob/6126a0bf46f4e29a368b8baefea69a2bcae54e93/compiler/semexprs.nim#L3171)
to also consider the overloads if the symbol kind is overloadable. But
it treats the normally overloadable template/macro/module sym kinds the
same as non-overloadable symbols, just calling `semSym` on it. We need
to mirror this behavior in `semOpenSym`; we treat the captured symchoice
as a fresh identifier, so if the symbol we find is a
template/macro/module, we use that symbol immediately as opposed to
waiting for overloads.
|
| |
|
|
|
|
|
|
|
|
| |
fixes #14522
fixes #22085
fixes #12700
fixes #23132
closes https://github.com/nim-lang/Nim/pull/22343 (succeeded by this PR)
completes https://github.com/nim-lang/RFCs/issues/175
follow up https://github.com/nim-lang/Nim/pull/12688
|
| |
|
|
|
| |
follows up https://github.com/nim-lang/Nim/pull/23064
fixes #23914
|
| |
|
| |
fixes #23907
|
| |
|
| |
fixes #23902
|
| |
|
| |
closes #6549
|
| |
|
| |
closes #21347
|
| |
|
|
|
|
|
| |
(#23895)
fixes #23894
keeps it consistent with `inc`
|
| |
|
|
|
|
|
|
|
|
| |
fixes #23865
The node flag `nfOpenSym` implemented in #23091 for sym nodes is now
also implemented for open symchoices. This means the intended behavior
is still achieved when multiple overloads are in scope to be captured,
so the issue is fixed. The code for the flag is documented and moved
into a helper proc and the experimental switch is now enabled for the
compiler test suite.
|
| |
|
| |
The test case diff is self explanatory
|
| |
|
|
|
|
| |
mutable (#23882)
Makes `toOpenArray(x: ptr UncheckedArray)` always return a `var
openArray` regardless of if `x` is mutable.
|
| |
|
| |
followup #23861
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Corrects a slicing mistake in the `std/varints` implementation which
caused it to fail when writing large numbers into buffers smaller than
10..13-bytes, now 9-byte buffers are sufficient as the documentation
states.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23853
Since #22610 generics turns the `Name` in the `GT.Name` expression in
the test code into a sym choice. The problem is when the compiler tries
to instantiate `GT.Name` it also instantiates the sym choice symbols.
`Name` has type `template (E: type ExtensionField)` which contains the
unresolved generic type `ExtensionField`, which the compiler mistakes as
an uninstantiated node, when it's just part of the type of the template.
The compilation of the node itself and hence overloading will handle the
instantiation of the proc, so we avoid instantiating it in `semtypinst`,
similar to how the first nodes of call nodes aren't instantiated.
|
| |
|
|
|
|
| |
fixes #23858
We should not assign fields to fields for returns of function calls
because calls might have side effects.
|
| |
|
|
|
|
| |
Fix https://github.com/nim-lang/Nim/issues/23547
Tested locally with the included test, the test from constantine and the
original issue.
|
| |
|
| |
fixes #23837
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23813, partially reverts #23392
Before #23392, if a `gensym` symbol was defined before a proc with the
same name in a template even with an `inject` annotation, the proc would
be `gensym`. After #23392 the proc was instead changed to be `inject` as
long as no `gensym` annotation was given. Now, to keep compatibility
with the old behavior, the behavior is changed back to infer the proc as
`gensym` when no `inject` annotation is given, however an explicit
`inject` annotation will still inject the proc. This is also documented
in the manual as the old behavior was undocumented and the new behavior
is slightly different.
|
| |
|
|
|
| |
follow up https://github.com/nim-lang/Nim/pull/23681
ref https://forum.nim-lang.org/t/11987
|
| |
|
|
|
|
|
|
| |
simple analysis (#23839)
follow up https://github.com/nim-lang/Nim/pull/23681
ref https://forum.nim-lang.org/t/11987
ref https://github.com/nim-lang/Nim/issues/23836#issuecomment-2227267251
|
| |
|
|
|
|
|
|
|
| |
Addresses #23825 by using the approaching described in
https://github.com/nim-lang/Nim/pull/23743#issuecomment-2199523110.
This takes the approach from Python's `subprocess` library which calls
`waitid` in loop, while sleeping at regular intervals.
CC @alex65536
|
| |
|
| |
#23823
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #3011
In https://github.com/nim-lang/Nim/pull/23532, meta fields that defined
in the object are handled.
In this PR, RefObjectTy is handled as well:
```nim
type
Type = ref object
context: ref object
```
Ref alias won't trigger mata fields checking so there won't have
cascaded errors on `TypeBase`.
```nim
type
TypeBase = object
context: ref object
Type = ref TypeBase
context: ref object
```
|
| |
|
| |
closes #22095
|
| |
|
|
| |
fixes #20865
fixes #20987
|
| |
|
|
| |
fixes #22389;
fixes #19840
|