| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
ref https://github.com/nim-lang/Nim/pull/23226
|
|
|
|
|
| |
(#23558)
fixes #23552
|
|
|
|
|
|
|
|
| |
This adds a version of `almostEqual` (which was already available for
floats) thata works with `Complex[SomeFloat]`.
Proof that this is needed is that the first thing that the complex.nim
runnable examples block did before this commit was define (an
incomplete) `almostEqual` function that worked with complex values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #23556
It should somehow handle default fields in the future
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
| |
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
|
|
|
|
| |
inputLen may end up as 0 in the loop if the input string only includes
trailing characters. e.g. without the patch, decode(" ") would panic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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);
};
```
|
|
|
|
|
|
|
| |
workaround #23435
related to https://github.com/nim-lang/Nim/issues/22852
see also #23279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #23499
In the
https://github.com/nim-lang/Nim/commit/8990626ca9715a3687b28331aee4ccf242997aa2
the effect of `skipAddr` changed to skip `nkAddr` and `nkHiddenAddr`.
Some old code was not adapted. In the
https://github.com/nim-lang/Nim/pull/23477, the magic `addr` function
was handled in the semantic analysis phase, which causes it be skipped
incorrectly
|
|
|
|
|
|
|
|
|
|
| |
variable `_` (#23498)
According to
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/Expression_statement,
some expression statements need parentheses to make it unambiguous. `_`
introduced in the https://github.com/nim-lang/Nim/pull/15789 is
unnecessary. We can get rid of it by adding parentheses so that object
literals are not ambiguous with block statements.
|
|
|
|
|
|
|
|
| |
fixes #4299
fixes #12492
fixes #10849
It binds `function` with `env`: `function.bind(:env)` to ease codegen
for now
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #23326
In a routine declaration node in a template, if the routine is marked as
`gensym`, the compiler adds it as a new symbol to a preliminary scope of
the template. If it's not marked as gensym, then it searches the
preliminary scope of the template for the name of the routine, then when
it matches a template parameter or a gensym identifier, the compiler
replaces the name node with a symbol node of the found symbol.
This makes sense for the template parameter since it has to be replaced
later, but not really for the gensym identifier, as it doesn't allow us
to inject a routine with the same name as an identifier previously
declared as gensym (the problem in #23326 is when this is in another
`when` branch).
However this is the only channel to reuse a gensym symbol in a
declaration, so maybe removing it has side effects. For example if we
have:
```nim
proc foo(x: int) {.gensym.} = discard
proc foo(x: float) {.gensym.} = discard
```
it will not behave the same as
```nim
proc foo(x: int) {.gensym.} = discard
proc foo(x: float) = discard
```
behaved previously, which maybe allowed overloading over the gensym'd
symbols.
A note to the "undeclared identifier" error message has also been added
for a potential error code that implicitly depended on the old behavior
might give, namely ``undeclared identifier: 'abc`gensym123'``, which
happens when in a template an identifier is first declared gensym in
code that doesn't compile, then as a routine which injects by default,
then the identifier is used.
|
|
|
|
|
|
| |
(#23481)
On POSIX, `std/encodings` uses iconv, and `iconv_open` returns
`(iconv_t) -1` on failure, not `NULL`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #16771
follow up https://github.com/nim-lang/Nim/pull/16536
Ideally it should be handled in the IR part in the future
I have also checked the double evaluation of `swap` in the JS runtime
https://github.com/nim-lang/Nim/issues/16779, that might be solved by a
copy flag or something. Well, it should be best solved in the IR so that
it doesn't bother backends anymore.
|
| |
|
|
|
| |
fixes #9550
|
| |
|
|
|
|
|
|
|
|
|
| |
fixes #23422
ref https://github.com/nim-lang/Nim/issues/20997
https://github.com/nim-lang/Nim/pull/21165
The function `cardSet` is used for large sets that are stored in the
form of arrays. It shouldn't be passed as a pointer
|
| |
|
|
|
|
|
|
|
|
| |
fixes #23399
The new case introduced in #21657 is triggered by `efWantStmt` but the
`when` statement doesn't normally propagate this flag, so propagate it
when the `semCheck` param in `semWhen` is true which happens when the
`when` statement is `efWhenStmt` anyway.
|
| |
|
|
|
|
|
|
|
|
| |
(#23377)
Windows's nodejs `isAbsolute` issue has been resolved by [this
PR](https://github.com/nim-lang/Nim/pull/23365).
So we can improve the coverage for Windows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lambdas (#23368)
fixes #22284
fixes #22282
```
Error: j(uRef, proc (config: F; sources: auto) {.raises: [].} = discard ) can raise an unlisted exception: Exception
```
The problem is that `n.typ.n` contains the effectList which shouldn't
appear in the parameter of a function defintion. We could not simply use
`n.typ.n` as `n[paramsPos]`. The effect lists should be stripped away
anyway.
|
|
|
| |
fixes #23378
|
|
|
| |
closes #22846
|
|
|
| |
closes #15751
|
|
|
|
|
|
| |
cstring to string via cstrToNimstr (#23371)
fixes #12703
ref #19588
|
|
|
| |
closes #10219
|
|
|
|
| |
Unfortunately we cant trick the debugger when targeting C++ so this one
also needs to wait for our own debugger adapter.
|
|
|
|
|
|
|
|
|
| |
ref #23354
The new move analyzer requires types that have the tfAsgn flag
(otherwise `lastRead` will return true); tfAsgn is included when the
destructor is not trival. But it should consider the assignement for
objects in this case because objects might have a trival destructors but
it's the assignement that matters when it is passed to sink parameters.
|
|
|
|
|
|
| |
fixes #13481;
fixes #22708
Otherwise it gives implicit results or bad codegen
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also prevents unwanted `raises: [ValueError]` effects from bubbling
up from correct format strings which makes `fmt` broadly unusable with
`raises`.
The old runtime-based `formatValue` overloads are kept for
backwards-compatibility, should anyone be using runtime format strings.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
|
|
|
| |
iterators and try/catch-like constructions (#23317)
|
|
|
| |
fixes #22723
|