* cleanups
* ast.nim: cleanups
* IC: no more sym.tab field, stored externally in the module graph
* nimble compiles again
* rodfiles: store bitwidth of integers and the endianness in the cookie because we serialize 'int' directly
* rodfiles: added compilerproc and export sections
* rodfiles: added all the missing sections
* rodfiles: track the missing information
* IC: architecture for lazy loading of proc bodies
* make tests green again
* completed the lazy loading of proc bodies
* symbol lookup integration, part 1
* symbol lookup integration, part 2
* symbol lookup integration, part 3
* make tcompilerapi work again
* rodfiles: fixed config change handling
nimsuggest outline should account for includes, now it does:
- the module prefix will be of the module doing the including
- the filename will be of the module that was included
- adds a test case for it
A number of nimsuggest tests were disabled for various reasons, sometimes due
to brittleness. These tests have been fixed where needed and most have are now
enabled -- details below. The updates are meant to provide better regression
coverage for future nimsuggest improvements. To avoid brittleness some tests
were refactored.
Impact:
* test coverage has now increased
* faster execution of the test suite
* tests are less likely to break due to stdlib changes
Re-enabled Test & Test Description:
* `tchk1.nim`: check (chk) via nimsuggest works at end of file
* `tdot4.nim`: prioritize already used completion
* `tinclude.nim`: definition lookup (def) with includes
* `tstrutils.nim` -> `tdef2.nim`: test template definition lookup (def)
* `tsug_regression.nim`: regression test for [nimsuggest #52](https://github.com/nim-lang/nimsuggest/issues/52)
* `ttemplate_highlight.nim`: per the file name
* `twithin_macro_prefix.nim`: suggest within a macro with a prefix
Tests Not Re-Enabled:
* `twithin_macro.nim` still disabled as it doesn't provide a good test signal
* EPC highlight tests remain disabled -- requires out of scope tester changes
Additional Notes:
* todos added in comments for follow-up work
This reverts commit a974684b14.
The CRLF was to separate between each response, and removing them causes
the responses to not be splitted correctly.
I didn't notice that it was in a loop when I made the #13545.
The line info should now points to the `a`, not the `*`, like this:
a*: string
^
Additionally this fixes nimsuggest's highlighting of exported object
fields.
This can be used to let nimsuggest users know which project is
nimsuggest being in charge of, so they can know when should a new
nimsuggest instance be spawned.
An additional feature is to debug the project file finding feature.
Same as e9fa4c9b9c, but for the epc
backend which is used by emacs and vscode plugin.
Since the EPC backend only deal with one connection per nimsuggest
instance, only one socket is leaked, thus not as servere as with the tcp
backend.
A new socket is created for each iteration and leak immediately thanks
to the accept() call replacing the created socket with the client socket.
This commit fixes that.
The default starting parameters for `line` and `col` were switched.
See line 141: "line starts at 1, column at 0, dirtyfile is optional".
Also, in `TLineInfo` object, `line` is uint16, `col` is int16.
* make fullpaths the default in error messages and stack traces for more convenient development
* split up -d:release into -d:release and -d:danger flags
* workaround a Nim config parser bug
* fixes an old nim config parser bug
* make megatest green again
* make nimpretty tests work again
* make nimsuggest green
Previously the compiler would generate suggestions based on the symbol
identifier length, but that might not reflect the actual representation
of it within the actual source code.
This commit implements a simple source scanner for the suggest module to
address the problem outlined above.
Fixesnim-lang/nimsuggest#24
* compiler/sem*: better lineinfo for templates
Lineinfo for templates is inconsistant across the compiler, for example:
doAssert true
^ ^
a[int](10)
^^ ^
The `^` marks where the compiler thinks the template starts.
For qualified call, we got the same situation with `proc`s before #10427:
system.once
^
Generics lineinfo within template declaration is also incorrect, for
example, this is where the compiler believes the `T` in `[T]` is:
template a[T](b: T)
^
This PR addresses all of these problems.
* nimsuggest: add tests for template highlighting
Previously the compiler will believe these are where `newSeq` symbol
starts:
newSeq[int]()
^
system.newSeq[int]()
^
This commit moves them back to:
newSeq[int]()
^
system.newSeq[int]()
^
