| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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???
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because `isGitRepo()` call requires `/bin/sh` it will always fail when
building Nim in a Nix build sandbox, and the check doesn't even make
sense if Nix already provides Nimble source code.
Since for Nimble `allowBundled` is set to `true` this effectlvely does
not change behavior for normal builds, but does avoid ugly hacks when
building in Nix which lacks `/bin/sh` and fails to call `git`.
Reference:
*
https://github.com/status-im/nimbus-eth2/pull/6180#discussion_r1570237858
Signed-off-by: Jakub Sokołowski <jakub@status.im>
|
| |
|
|
|
| |
refs (#23507)
fixes #23505
|
| |
|
|
|
| |
Was introduced to handle a break in #23392, according to
https://github.com/nim-lang/Nim/pull/23503#issuecomment-2057266475
should not be needed anymore
|
| |
|
| |
fixes #23494
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
(#23501)
…he compiler
|
| |
|
|
|
| |
fixes #23487
uses JSRef
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Hi,
This is a tiny change, fixing the error in the documentation of JSON's
deep copy proc.
|
| |
|
|
|
|
|
|
| |
fixes #4299
fixes #12492
fixes #10849
It binds `function` with `env`: `function.bind(:env)` to ease codegen
for now
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a second example inside the `typedthreads` file.
Also, add a more detailed introduction. When Nim is one's first
programming language, a short explanation of what a thread is might not
hurt.
For reference, the thread documentation of other languages looks like
this:
- https://en.cppreference.com/w/cpp/thread/thread
- https://doc.rust-lang.org/std/thread/
The documentation of a module is the first place one will look when
using a standard library feature, so I think it is important to have a
few usable examples for the main modules.
This is the example added
```nim
import locks
var l: Lock
proc threadFunc(obj: ptr seq[int]) {.thread.} =
withLock l:
for i in 0..<100:
obj[].add(obj[].len * obj[].len)
proc threadHandler() =
var thr: array[0..4, Thread[ptr seq[int]]]
var s = newSeq[int]()
for i in 0..high(thr):
createThread(thr[i], threadFunc, s.addr)
joinThreads(thr)
echo s
initLock(l)
threadHandler()
deinitLock(l)
```
Sharing memory between threads is very very common, so I think having an
example showcasing this is crucial.
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
|
| | |
|
| |
|
| |
mIntToStr, mInt64ToStr, mFloatToStr,
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #23440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
the function name extension encoded by paths could be useful for
debugging where the function is from
Before:
```js
function newSeq_33556909(len_33556911)
```
After:
```js
function newSeq__system_u2477(len_p0)
```
|
| | |
|
| |
|
|
|
|
| |
ref https://github.com/nim-lang/website/issues/391
https://news.ycombinator.com/item?id=38419134
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
## Reprodution
if on Windows:
```Nim
when defined(windows):
var file: File
let succ = file.open(<aFileHandle>)
```
then `succ` will be false.
If tested, it can be found to fail with errno `22` and message: `Invalid
argument`
## Problem
After some investigations and tests,
I found it's due to the `mode` argument for `fdopen`.
Currently `NoInheritFlag`(`'N'` in Windows) is added to `mode` arg
passed to `_fdopen`, but if referring to
[Windows `_fdopen`
doc](https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fdopen-wfdopen?view=msvc-170),
you'll find there is no `'N'` describled. That's `'N'` is not accepted
by `_fdopen`.
Therefore, the demo above will fail.
## In Addition
To begin with, technologically speaking, when opening with a
`fileHandle`(or called `fd`), there is no concept of fd-inheritable as
`fd` is opened already.
In POSIX, `NoInheritFlag` is defined as `e`.
It's pointed out in [POSIX `open`
man-doc](https://www.man7.org/linux/man-pages/man3/fopen.3.html) that
`e` in mode is ignored for fdopen(),
which means `e` for `fdopen()` is not wanted, just allowed.
Therefore, better to also not pass `e` to `fdopen`
---
In all, that's this PR.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ref https://forum.nim-lang.org/t/11338
ref https://github.com/beef331/wasm3/blob/master/src/wasm3/exporter.nim
ref https://github.com/emscripten-core/emscripten/issues/6233
ref
https://github.com/emscripten-core/emscripten/blob/3.1.56/system/include/emscripten/em_macros.h#L10
`EMSCRIPTEN_KEEPALIVE` is a macro that is used to prevent unused
functions from being deadcode eliminated in emscripten, which is a
simple wrapper around `__attribute__((used))`. This PR follows suits and
expects dynlib is supposed to keep these functions alive. In the future,
`exportwasm` might be introduced.
After this PR, a function with `{.dynlib, exportc.}` can be reused from
other wasm programs reliably.
|
| |
|
| |
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 #23429
|
| |
|
| |
Refer to the discussion in #23439.
|
| |
|
|
|
|
|
|
|
|
| |
internal errors to fatal errors. (#23443)
This fixes a nimsuggest crash when opening:
beacon_chain/consensus_object_pools/blockchain_dag.nim
from the nimbus-eth2 project and many other .nim files (44 files, to be
precise) in the same project.
Replaces: https://github.com/nim-lang/Nim/pull/23402
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
where sizeof(int) < 4 (#23433)
Fixes an issue that comes up when using strutils.`%` or any other
strutils/strformat feature that uses the unicode lookup tables behind
the scenes, on systems where ints are than 32-bit wide.
Tested with:
```bash
./koch test cat lib
```
Refer to the discussion in #23125.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The fix to the atomicArc looks to use `-1` as the check value from the
`SharedPtr` solution. However, it should be `-rcIncrement` since the
refcount is bit shifted in ARC/ORC.
I discovered this playing around doing atomic updates of refcounts in a
user library.
Related to https://github.com/nim-lang/Nim/issues/22711
@ringabout I believe you ported the sharedptr fix?
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
# Description
When using `--hintAsError`, we want some red color to appear in the
logs.
Same is already done for `warningAsError`.
# Cherry-picking to Nim 1.6
Would be nice to cherry-pick this and the `warningAsError` log highlight
to 1.6 branch, as it's used in status-desktop.
|
| | |
|
| |
|
| |
adding link to generic == for tuples in Open and Closed symbols example
|
| |
|
| |
fixes #23401
|
| |
|
| |
Signed-off-by: soonsouth <cuibuwei@163.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds nimsuggest support for displaying inlay hints for exceptions.
An inlay hint is displayed around function calls, that can raise an
exception, which isn't handled in the current subroutine (in other
words, exceptions that can propagate back to the caller). On mouse hover
on top of the hint, a list of exceptions that could propagate is shown.
The changes, required to support this are already commited to
nimlangserver and the VS code extension. The extension and the server
allow configuration for whether these new exception hints are enabled
(they can be enabled or disabled independently from the type hints), as
well as the inlay strings that are inserted before and after the name of
the function, around the function call. Potentially, one of these
strings can be empty, for example, the user can choose to add an inlay
hint only before the name of the function, or only after the name of the
function.
|
| |
|
|
|
| |
Problem described here: https://github.com/karaxnim/karax/issues/284
Co-authored-by: Chancy Kennedy <chancy@conciergecloset.com>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
fix #23381
As for the read function, the original plan was to use lent for
annotation, but after my experiments, it still produced copies, so I had
to move it out.
Now the `read` function cannot be called repeatedly
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
fixes #23382
follow up https://github.com/nim-lang/Nim/pull/15823
|
| |
|
|
| |
pragma (#23369)
|