| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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
|
|
|
|
|
|
|
| |
makes new hash the default, with an opt-out (& js-no-big-int) define.
Also update changelog (& fix one typo).
Only really expect the chronos hash-order sensitive test to fail until
they merge that PR and tag a new release.
|
|
|
|
|
| |
functions in cpp (#23800)
fixes #23796
|
|
|
| |
fixes #23790
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pr redefines the relation between lambda lifting and closureiter
transformation.
Key takeaways:
- Lambdalifting now has less distinction between closureiters and
regular closures. Namely instead of lifting _all_ closureiter variables,
it lifts only those variables it would also lift for simple closure,
i.e. those not owned by the closure.
- It is now closureiter transformation's responsibility to lift all the
locals that need lifting and are not lifted by lambdalifting. So now we
lift only those locals that appear in more than one state. The rest
remains on stack, yay!
- Closureiter transformation always relies on the closure env param
created by lambdalifting. Special care taken to make lambdalifting
create it even in cases when it's "too early" to lift.
- Environments created by lambdalifting will contain `:state` only for
closureiters, whereas previously any closure env contained it.
IMO this is a more reasonable approach as it simplifies not only
lambdalifting, but transf too (e.g. freshVarsForClosureIters is now gone
for good).
I tried to organize the changes logically by commits, so it might be
easier to review this on per commit basis.
Some ugliness:
- Adding lifting to closureiters transformation I had to repeat this
matching of `return result = value` node. I tried to understand why it
is needed, but that was just another rabbit hole, so I left it for
another time. @Araq your input is welcome.
- In the last commit I've reused currently undocumented `liftLocals`
pragma for symbols so that closureiter transformation will forcefully
lift those even if they don't require lifting otherwise. This is needed
for [yasync](https://github.com/yglukhov/yasync) or else it will be very
sad.
Overall I'm quite happy with the results, I'm seeing some noticeable
code size reductions in my projects. Heavy closureiter/async users,
please give it a go.
|
|
|
|
|
|
|
| |
fixes #23784
notes that before https://github.com/nim-lang/Nim/pull/23477, it didn't
fold paths containing `addr`/`unsafeAddr` because it retained the form
of the magic function: `mAddr`.
|
|
|
|
|
| |
(for `string` or any other key type). Independence is nice to ever
change orders. So, change it to just `len` & a `doAssert` like the other
test in the same file.
|
|
|
| |
fixes #23775
|
|
|
|
|
|
|
| |
#23755
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
|
|
|
|
| |
Fixes #5091.
Ensure we don't wait on an exited process on Linux
|
|
|
|
|
| |
arguments (#23769)
fixes #23748
|
|
|
|
|
|
|
|
|
| |
```
$ curl -v http://example.com/404 |& grep 'HTTP/1.1'
> GET /404 HTTP/1.1
< HTTP/1.1 500 Internal Server Error
```
So, the test with http://example.com/404 should be disabled, I think.
|
|
|
| |
fixes #23759
|
|
|
|
|
| |
refc [backport] (#23761)
fixes #9940
|
|
|
|
|
|
|
|
| |
fixes #23749, refs #22716
`semIndirectOp` is used here because of the callback expressions, in
this case `db.getProc(...)`, and `semIndirectOp` calls `semOpAux` to
type its arguments before overloading starts. Hence it can opt in to
symchoices since overloading will resolve them.
|
|
|
|
| |
Assuming CI tests pass (they do for me locally), this should be merged
to keep them passing.
|
|
|
| |
fixes #23711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unlike present Nim this actually fills `Hash` for `string` & related.
For the curious, note that `hashData` remains the aboriginal Nim string
hasher & `import hashes {.all.}` allows simultaneous test/time of {orig,
murmur, farm} on your favorite CPU & back end compiler.
Update tests also conditioned upon `nimPreviewHashFarm` so they should
pass either with or without that `define` on.
In `--jsbigint=on` mode, only the lower 32-bits of `Hash` match nimvm &
run-time values because `type Hash = int` and on JS int=int32, not int64
as for 64-bit Nim platforms. Due to the matching, `const` Table should
match run-time `Table` on all platforms.
To operate in `--jsbigint=off` mode is feasible but needs much "double
precision mul/xor/ror/shr-arithmetic"-style work. That is distracting &
also of questionable value since JS added BigInt in 2018, ringabout
added Nim support for it in 2021 & `nimPreviewHashFarm` is unlikely to
swap from an opt-in to an opt-out default before 2025..2026 which will
have given a backward looking time window of 7..8 years for deployment
platforms - reasonably generous.
Add a changelog entry for 2.2.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
type (#23608)
fixes #20048
fixes #15746
|