Erlang LS identifies functions, types and parameterised macros as
`name/arity`, but `/` separates the components of a Serena name path, so
`create_user/4` was parsed as "symbol `4` nested inside `create_user`" and
could never match -- not even via the name path Serena itself reported for
the symbol. Browsing still worked, but find_referencing_symbols,
replace_symbol_body and insert_after_symbol were unusable on Erlang
functions.
Normalize the name to `create_user#4` instead. `#` cannot occur in an
unquoted Erlang atom, so it can never collide with a real name, unlike `@`.
The arity is kept rather than stripped because it is part of a function's
identity in Erlang: create_order/3 and create_order/2 are different
functions and may coexist in one module.
Also document the "no `/` in symbol names" rule on _normalize_symbol_name,
which is what the next backend for such a language needs to know.
Adds tests for name resolution for each language and fixes the name resolution where tests have failed.
Also:
Extends python tests to cover ty
Extends skipping conditions for several LS (but only when not in CI)
Better test output in CI
Removed a wrong python test (started failing for ty and should have failed for pyright too)
Black dependency created a dependabot warning and couldn't be bumped since it collided with pathspec dependencies. Since ruff can also format, black is not needed. But we now have these small format changes, mostly in test files
* Introduce SymbolBody representation (compact), from which the
body can be reconstructed, rendering body computation lazy
* Introduce SymbolBodyFactory for the creation of such instances,
ensuring that instances created from the same factory share
the same file content, allowing the in-memory and on-disk caches
to have a significantly smaller memory footprint
* Change type of "body" key in UnifiedSymbolRepresentation to use
SymbolBody instead of str
* Adjust all usages of the "body" key
Unlike other language servers, metals LS only works properly when the project has been compiled in a particular way. Compiling like this on the fly or in CI is unfeasible, so instead, we expect the user to setup and compile the project correctly when using Serena for scala. Extensive documentation has been added.
Scala tests exist, but we don't run them in CI. They have been executed manually on macOS and Windows, thereby verifying that after following the instructions, Scala support works in Serena.
Dominik Jain