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 (cherry picked from
commit c934d5986d)
fixes#22753
## Future work
We should turn all the error nodes into nodes of a nkError kind, which
could be a industrious task. But perhaps we can add a special treatment
for error nodes to make the transition smooth.
(cherry picked from commit 642ac0c1c3)
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Currently when using `use` with nimsuggest on an enum field, it doesn't
return the definition of the field.
Breaks renaming in IDEs since it will replace all the usages, but not
the declaration
(cherry picked from commit c31bbb07fb)
When it is specified, the nimsuggest instance monitors whether this
process is still alive. In case it's found to be dead, nimsuggest shuts
itself down. Currently only implemented on POSIX and Windows platforms.
The switch is silently ignored on other platforms. Note that the Nim
language server should still try to shut down its child nimsuggest
processes. This switch just adds extra protection against crashing Nim
language server and gets rid of the remaining nimsuggest processes,
which consume memory and system resources.
(cherry picked from commit 502a4486ae)
Refactored the way nimsuggest checks for protocol version 3. Instead of
checking for version 3 exactly, it now checks for version 3 or later.
This way, once a version 4 is introduced, it will use version 3 as a
base line, and then extra changes to the protocol can be added on top.
No functional changes are introduced in this commit.
(cherry picked from commit 3680200df4)
* fix getNullValue for cstring in VM
fixes#22524
* very ugly fixes, but fix#15730
* nil cstring len works, more test lines
* fix high
(cherry picked from commit 942f846f04)
Close#17509
Current knowledge:
- delaying cache fixes the issue
- changing return of `if inst.len < key.len:` in `searchInstTypes` to
`continue` fixes the issue. With return the broken types are also cached
over and over
Related issues are completely unaffected as of now, so there must be
something deeper.
I am also still trying to find the true cause, so feel free to ignore
for now
---------
Co-authored-by: SirOlaf <>
(cherry picked from commit ee4a219012)
* Add test case
* Add in a bounds check when accessing generic types
Removes idnex out of bounds exception when comparing a generic that isn't fully instantiated
(cherry picked from commit 3efabd3ec6)
* Add tests
Also test if exported all tuple fields works. This seems like a hacky solution so will try and dive further to find a better solution
* Always suggest tuple fields if it passes the filter
If the tuple we are accessing is in scope then all the fields will also be in scope
* Update tests so line numbers are correct
(cherry picked from commit 1b132ddaa2)
* fixes#21231; template with module as parameter elides usage/checking of module name specifier
* add a test case
(cherry picked from commit ac7b8b678c)
