fixes#23499
In the
8990626ca9
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
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>
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.
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)
```
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.
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
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.
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.
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#22284fixes#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.
