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
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.
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
# 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.
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.
Currently, I don't have syntax highlighting (+ no/wrong
jump-to-definition) for some import statement forms, namely:
- `import module/name/with/(slashes)`
- `import (mod) as alias`
- `import basemod/[ (sub1), (sub2) ]`
With this patch, highlight/def will work for the regions indicated by
parentheses.
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.
This is just one of those tiny steps towards the goal of an "optimized"
C and C++ codegen I raised elsewhere before - what does me babbling
"optimized" mainly entail?
(not mutually-exclusive ascertainment proposals following:)
- less and simplified resulting code: easier to pick up/grasp for the
C/C++ compiler for to do its own optimization heuristics, less parsing
effort for us mere humans trying to debug, especially in the case of
interop
- build time reduction: less code emission I/O, runtime string
formatting for output...
- easier access for fresh contributors and better maintainability
- interop improvements
- further runtime optimizations
I am eagerly looking forward to the results of the LLVM-based
undertakings, but I also think we can do a bit better (as outlined
above) with our current C/C++ backends till those come to fruition.
**Long story short**: this PR here focuses on the C++ backend,
augmenting the current codegen method of establishing "temporary"
variables by using C++11's auto type deduction. The reasons for adopting
an "Almost Always Auto" style have been collected [here
](https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/)
for the C++ world. For those hopping between C++'s and Nim's realms,
this change also results in a bit less code and less work for the
codegen part (no redundant `getTypeDesc`s): no need to tell the C++
compiler the type it already knows of (in most cases).
This fixes an oversight with a change that I made a while ago.
Basically, these two snippets should both compile. Currently the
`varargs` version will fail.
```nim
template s(d: typed)=discard
proc something()=discard
proc something(x:int)=discard
s(something)
```
```nim
template s(d: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s(something)
```
Potentially unrelated, but this works currently for some reason:
```nim
template s(a: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s:
something
```
also, this works:
```nim
template s(b:untyped, a: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s (g: int):
something
```
but this doesn't, and the error message is not what I would expect:
```nim
template s(b:untyped, a: varargs[typed])=discard
proc something()=discard
proc something(x:int)=discard
s (g: int), something
```
So far as I can tell, none of these issues persist for me after the code
changes in this PR.
The following would crash nimsuggest on init:
```nim
import chronos
type
HistoryQuery = object
start: int
limit: int
HistoryResult = object
messages: string
type HistoryQueryHandler* = proc(req: HistoryQuery): Future[HistoryResult] {.async, gcsafe.}
```
…hich conveys effects beyond its module scope for C/C++
codegen(suppresses current UnusedImport warning)
Just a minor inconvenience working in the area of C/C++ integration I
guess, but here we go:
I noticed receiving ```UnusedImport``` warnings for modules having only
```passC```/```passL```/```compile``` pragmas around. I gather the
compiler cannot actually infer those modules being unused as they *may*
have consequences for the whole build process (as they did in my simple
case).
Thus, I hereby suggest adding the `sfUsed` flag to the respective module
in order to suppress the compiler's warning.
I reckon other pragmas should be put into consideration as well: I will
keep up the investigation with PR followups.
