| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23690
```nim
dest.`:state` = src.`:state`
var :tmp_553651276 = dest.e1.a
`=wasMoved`(dest.e1.a)
dest.e1.a.kind = src.e1.a.kind
case dest.e1.a.kind
of 0:
dest.e1.a.a = src.e1.a.a
of 1:
`=copy`(dest.e1.a.c, src.e1.a.c)
case :tmp_553651276.kind
of 0:
of 1:
`=destroy`(:tmp_553651276.c)
```
`dest.e1.a.kind = src.e1.a.kind` changes the discrimant but it fails to
clear the memory of `dest.e1.a`. Before using hooks for copying, we need
to clear the dest, e.g. `=wasMoved(dest.e1.a.c)`.
```nim
dest.`:state` = src.`:state`
var :tmp_553651276 = dest.e1.a
`=wasMoved`(dest.e1.a)
dest.e1.a.kind = src.e1.a.kind
case dest.e1.a.kind
of 0:
`=wasMoved`(dest.e1.a.a)
dest.e1.a.a = src.e1.a.a
`=wasMoved`(dest.e1.a.b)
of 1:
`=wasMoved`(dest.e1.a.c)
`=copy`(dest.e1.a.c, src.e1.a.c)
case :tmp_553651276.kind
of 0:
of 1:
`=destroy`(:tmp_553651276.c)
```
|
| | |
|
| | |
|
| | |
|
| |
|
| |
fixes #22672
|
| |
|
|
|
|
|
|
|
| |
follow up https://github.com/nim-lang/Nim/pull/6265
fixes #5901
fixes #21211
It causes many problems with gcc14 if we fold the cast function types.
Let's check what it will break
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #10440, fixes #13871, fixes #14665, fixes #19672, fixes #23677
The false positive in #23677 was caused by behavior in
`implicitlyDiscardable` where only the last node of `if`/`case`/`try`
etc expressions were considered, as in the final node of the final
branch (in this case `else`). To fix this we use the same iteration in
`implicitlyDiscardable` that we use in `endsInNoReturn`, with the
difference that for an `if`/`case`/`try` statement to be implicitly
discardable, all of its branches must be implicitly discardable.
`noreturn` calls are also considered implicitly discardable for this
reason, otherwise stuff like `if true: discardableCall() else: error()`
doesn't compile.
However `endsInNoReturn` also had bugs, one where `finally` was
considered in noreturn checking when it shouldn't, another where only
`nkIfStmt` was checked and not `nkIfExpr`, and the node given for the
error message was bad. So `endsInNoReturn` now skips over
`skipForDiscardable` which no longer contains
`nkIfStmt`/`nkCaseStmt`/`nkTryStmt`, stores the first encountered
returning node in a var parameter for the error message, and handles
`finally` and `nkIfExpr`.
Fixing #23677 already broke a line in `syncio` so some package code
might be affected.
|
| |
|
|
|
| |
The files(like `build/build.sh`)generated by the command `koch csource`
do not contain complete `linux/loongarch64` support. This patch will fix
it.
|
| |
|
|
|
|
|
| |
blocks https://github.com/nim-lang/Nim/pull/23673
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| | |
|
| |
|
|
| |
(#23654)
|
| |
|
|
|
| |
(#23666)
…his scope
|
| |
|
| |
fixes #23665
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
seq[T] with index out of range (#23279)
follow up https://github.com/nim-lang/Nim/pull/23013
fixes #22852
fixes #23435
fixes #23645
reports rangeDefect correctly
```nim
/workspaces/Nim/test9.nim(1) test9
/workspaces/Nim/lib/system/indices.nim(116) []
/workspaces/Nim/lib/system/fatal.nim(53) sysFatal
Error: unhandled exception: value out of range: -2 notin 0 .. 9223372036854775807 [RangeDefect]
```
|
| |
|
|
| |
(#23640)
|
| | |
|
| |
|
|
| |
(#23633)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23627
```nim
type
TestObj = object of RootObj
TestTestObj = object of RootObj
testo: TestObj
proc `=destroy`(x: TestTestObj) =
echo "Destructor for TestTestObj"
proc testCaseT() =
echo "\nTest Case T"
let tt1 {.used.} = TestTestObj(testo: TestObj())
```
When generating const object fields, it's likely that
we need to generate type infos for the object, which may be an object
with
custom hooks. We need to generate potential consts in the hooks first.
https://github.com/nim-lang/Nim/pull/20433 changed the semantics of
initialization. It should evaluate`BracedInit` first.
|
| |
|
|
|
| |
fixes #16671
related to https://github.com/nim-lang/Nim/pull/18911
|
| |
|
|
|
| |
I could trivially port Nim to NetBSD/aarch64 because it already
supported NetBSD and aarch64. I only needed to generate `c_code` for
this combination.
|
| |
|
|
|
| |
ref https://forum.nim-lang.org/t/11587
Tested with `gcc version 14.0.1 20240412` locally
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23596
When importing a module and declaring an overloadable symbol with the
same name as the module in the same scope, the module symbol can take
over and make the declared overload impossible to access. Previously
enum overloading had a quirk that bypassed this in a context where a
specific enum type was expected but this was removed in #23588. Now this
is bypassed in every place where a specific type is expected since
module symbols don't have a type and so wouldn't be compatible anyway.
But the issue still exists in places where no type is expected like `let
x = modulename`. I don't see a way of fixing this without nerfing module
symbols to the point where they're not accessible by default, which
might break some macro code.
|
| |
|
|
| |
By allowing `exportc` in params one can decide the name of a param or to
dont mangle them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ref https://forum.nim-lang.org/t/11564
```nim
block: # unordered enum
block:
type
unordered_enum = enum
a = 1
b = 0
doAssert (ord(a), ord(b)) == (1, 0)
block:
type
unordered_enum = enum
a = 1
b = 0
c
doAssert (ord(a), ord(b), ord(c)) == (1, 0, 2)
block:
type
unordered_enum = enum
a = 100
b
c = 50
d
doAssert (ord(a), ord(b), ord(c), ord(d)) == (100, 101, 50, 51)
block:
type
unordered_enum = enum
a = 7
b = 6
c = 5
d
doAssert (ord(a), ord(b), ord(c), ord(d)) == (7, 6, 5, 8)
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
refs
https://github.com/nim-lang/Nim/issues/23586#issuecomment-2102113750
In #20091 a bad kind of type inference was mistakenly left in where if
an identifier `abc` had an expected type of an enum type `Enum`, and
`Enum` had a member called `abc`, the identifier would change to be that
enum member. This causes bugs where a local symbol can have the same
name as an enum member but have a different value. I had assumed this
behavior was removed since but it wasn't, and CI seems to pass having it
removed.
A separate PR needs to be made for the 2.0 branch because these lines
were moved around during a refactoring in #23123 which is not in 2.0.
|
| |
|
|
|
| |
(#23558)
fixes #23552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
`reset`, `wasMoved` and `move` doesn't support primitive types, which
generate `null` for these types. It is now produce `x = default(...)` in
the backend. Ideally it should be done by ast2ir in the future
|
| |
|
| |
fixes #22409
|
| | |
|
| |
|
|
|
|
|
|
|
| |
fixes #23419
`void` is only supported as fields of objects/tuples. It shouldn't allow
void in the array.
I didn't merge it with taField because that flag is also used for
tyLent, which is allowed in the fields of other types.
|
| |
|
|
|
|
|
|
| |
fixes #23321
In the function `mapType`, ptrs (tyPtr, tyVar, tyLent, tyRef)
are mapped into ctPtrToArray, the dereference of which is skipped
in the `genref`. We need to skip these ptrs in the function
`genOpenArraySlice`.
|
| |
|
|
|
| |
fixes #23531
fixes #19546
fixes #6982
|
| |
|
|
|
| |
for loop (#23540)
fixes #23536
|
| |
|
| |
fixes #23522
|
| |
|
| |
fixes #23525
|
| |
|
| |
ref https://github.com/nim-lang/Nim/issues/9550
|
| |
|
|
|
|
|
|
|
|
|
|
| |
fixes #23524
```nim
proc isAnalysableFieldAccess*(orig: PNode; owner: PSym): bool =
...
result = n.kind == nkSym and n.sym.owner == owner and
{sfGlobal, sfThread, sfCursor} * n.sym.flags == {} and
(n.sym.kind != skParam or isSinkParam(n.sym))
```
In `isAnalysableFieldAccess`, globals, cursors are already rejected
|
| |
|
|
| |
Previously, in certain cases, the compiler would generate debug info for
the correct line number, but for the wrong .nim source file.
|
| | |
|
| |
|
|
|
|
| |
This solution should resolve the nimsuggest crash issue. However,
perhaps the problem is in the parser?
fix #23518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#23388)
…instantiations (C/C++ backend)
AFAIK, #22802 expanded `noinit`'s utility by allowing the pragma to be
attached to types (thanks @jmgomez !).
I suggest broadening the scope a bit further: try to avoid `nimZeroMem`s
on a type level beyond imported C/C++ types[^1], saving us from
annotating the type instantiations with `noinit`.
If this change is deemed acceptable, I will also adjust the docs, of
course.
Adding tests for this change seems a bit problematic, as the effect of
this type annotation will be to work with uninitialized memory, which
*might* match 0 patterns.
[^1]: "complex value types" as already defined here:
https://github.com/nim-lang/Nim/blob/94c599687796f4ee3872c8aa866827b9ed33f52b/compiler/cgen.nim#L470-L471
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When forward declaration is used with pragmas `virtual` or `member`, the
declaration in struct is added twice. It happens because of missing
check for `sfWasForwarded` pragma.
Current compiler generates the following C++ code:
```cpp
struct tyObject_Foo__fFO9b6HU7kRnKB9aJA1RApKw {
N_LIB_PRIVATE N_NOCONV(void, abc)(NI x_p1);
N_LIB_PRIVATE N_NOCONV(virtual void, def)(NI y_p1);
N_LIB_PRIVATE N_NOCONV(void, abc)(NI x_p1);
N_LIB_PRIVATE N_NOCONV(virtual void, def)(NI y_p1);
};
```
|
| |
|
|
| |
follow up https://github.com/nim-lang/Nim/pull/7606
https://github.com/nim-lang/Nim/pull/13466
|
| |
|
| |
introduced in https://github.com/nim-lang/Nim/pull/9411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23492
```nim
proc foo =
var x: range[1.0 .. 5.0] = 2.0
case x
of 1.0..2.0:
echo 1
else:
echo 3
foo()
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #4695
ref https://github.com/nim-lang/Nim/pull/15818
Since `nkState` is only for the main loop state labels and `nkGotoState`
is used only for dispatching the `:state` (since
https://github.com/nim-lang/Nim/pull/7770), it's feasible to rewrite the
loop body into a single case-based dispatcher, which enables support for
JS, VM backend. `nkState` Node is replaced by a label and Node pair and
`nkGotoState` is only used for intermediary processing. Backends only
need to implement `nkBreakState` and `closureIterSetupExc` to support
closure iterators.
pending https://github.com/nim-lang/Nim/pull/23484
<del> I also observed some performance boost for C backend in the
release mode (not in the danger mode though, I suppose the old
implementation is optimized into computed goto in the danger mode)
</del>
allPathsAsgnResult???
|
| |
|
|
|
| |
refs (#23507)
fixes #23505
|
| |
|
| |
fixes #23494
|