* optimize document symbol generation
* match folding range index to position conversion and documentation to document symbol's
* skip function decls with no name
* skip document symbol field in opaque type
* Fix build runner
* Add zls module, bump version
* Fix path from root issue in modules (thanks daremakemyday from Twitch :))
* Libraryify
* remove build_runner backward compatibility
* Remove some `= undefined`s in Server.zig
Makes library use less dangerous
* Consistent mem model + custom build runner possible
* Add build runner utils for third-party tooling
* Make logs removable in libraries with zls_ prefix
* Fix build runner CI
* Expose references
* Use new addModule
* InternPool: replace untyped values with typed values
* InternPool: remove `indexToTag`
* InternPool: rework representation of optional values
* add representation for unknown values and types
* ComptimeInterpreter: use InternPool typed-values
* ComptimeInterpreter: field access test
* ComptimeInterpreter: improve handling of if expressions
* InternPool: fix typeOf on a comptime float
* ComptimeInterpreter: implement TypeOf with multiple parameters
* support new module cli arguments
* capture the runtime zig version and store it on `Server`
* update build_runner action
* Use correct version for selecting arguments
* run `zig fmt`
* add support for multi object for loops
* add completion tests on multi object for loops
* update minimum zig build version
* use multi object for loops in codebase
* Update tres to latest version
* fix panics when generating document scope on invalid for loops
Before, the code lexed only a prefix of the line up to cursor position.
Now, we lex the entire line, and do look at the token just after the
cursor.
This subtly changes sematncih of `getPostionContext`: now it is becomes
oblivious of the _exact_ position of the cursor and returns the whole
token at cursor's position.
I believe this is semantically right approach -- _most_ of the callsite
should not worry at all about such details. Something like completion
_might_ want to know more, but it's better to make that call site's
problem.
It might be the case that some existing code relies on the past
behavior. It's hard to tell though -- we don't have a lot of tests for
_features_, and changes to unit-tests don't explain if the changes are
meaningful for user-observable behavior or not.
In general, for LSP-shaped thing, I feel that the bulk of testing should
be focused on end-to-end behaviors....
