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?
`ProjectWorkspace::to_roots` now returns a new `ProjectRoot` which contains
information regarding whether or not the given path is part of the current
workspace or an external dependency. This information can then be used in
`ra_batch` and `ra_lsp_server` to implement more advanced filtering. This allows
us to filter some unnecessary folders from external dependencies such as tests,
examples and benches.
If the client doesn't specify this explicitly, that very likely means it doesn't
know about it and so we shouldn't send decorations. In particular, the recent
change to this default caused decorations to be sent to emacs, resulting in a
lot of warning spam.
948: Fix test_missing_module_code_action_in_json_project on Windows r=matklad a=vipentti
The test would fail on Windows due to the paths not being properly escaped for
JSON.
In addition adds extra braces around the fn main to actually introduce braces in
the file.
Co-authored-by: Ville Penttinen <villem.penttinen@gmail.com>
The test would fail on Windows due to the paths not being properly escaped for
JSON.
In addition adds extra braces around the fn main to actually introduce braces in
the file.
This allows users to control whether or not they want to see the "workspace
loaded" notification.
This is done on the server side using InitializationOptions which are provided
by the client. By default show_workspace_loaded is true, meaning the
notification is sent.
This now allows us to send a notification that can be shown in the UI when the
workspace has been loaded.
Additionally this removes the need for internal_mode flag.
