This appears to have been introduced ages ago in
be742a5877
but has since been removed.
As it stands, it is problematic if multiple instances of the
rust-analyzer LSP are launched during the same VS Code session because
VS Code complains about multiple LSP servers trying to register the
same command.
Most LSP servers workaround this by parameterizing the command by the
process id. For example, this is where `rls` does this:
ff0b9057c8/rls/src/server/mod.rs (L413-L421)
Though `apply_code_action` does not seems to be used, so it seems better
to delete it than to parameterize it.
This wasn't a right decision in the first place, the feature flag was
broken in the last rustfmt release, and syntax highlighting of imports
is more important anyway
Very simple approach: For each identifier, set the hash of the range
where it's defined as its 'id' and use it in the VSCode extension to
generate unique colors.
Thus, the generated colors are per-file. They are also quite fragile,
and I'm not entirely sure why. Looks like we need to make sure the
same ranges aren't overwritten by a later request?
Implements a pretty barebones function signature help mechanism in
the language server.
Users can use `Analysis::resolve_callback()` to get basic information
about a call site.
Fixes#102
