2772: Actually test references r=kjeremy a=kjeremy
This will be a little more work when `ReferenceSearchResults` change but I think it's easier to maintain in the end. It also follows a similar pattern to navigation targets and call hierarchy.
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
Let's be always explicit whether we create a library (i.e., an immutable
dependency) or a local `SourceRoot`, since it can have a large impact on
the validation performance in salsa. (we found it the hard way recently,
where the `Default` instance made it quite tricky to spot a bug)
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
When processing a change with added libraries, we used
`Default::default` for `SourceRoot` which sets `is_library` to false.
Since we use `is_library` to decide whether to use low or high
durability, I believe that this caused us to mark many library
dependencies as having low durability and thus increased the size of the
graph that salsa needed to verify on every change.
Based on my initial tests this speeds up the `CrateDefMapQuery` on
rust-analyzer from about ~64ms to ~14ms and reduces the number of
validations for the query from over 60k to about 7k.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
This change:
- introduces `compute_crate_def_map` query and renames
`CrateDefMap::crate_def_map_query` for consistency,
- annotates `crate_def_map` as `salsa::transparent` and adds a
top-level `crate_def_map` wrapper function around that starts the
profiler and immediately calls into `compute_crate_def_map` query.
This allows us to better understand where we spent the time, in
particular, how much is spent in the recomputaiton and how much in
salsa.
Example output (where we don't actually re-compute anything, but the
query still takes a non-trivial amount of time):
```
211ms - handle_inlay_hints
150ms - get_inlay_hints
150ms - SourceAnalyzer::new
65ms - def_with_body_from_child_node
65ms - analyze_container
65ms - analyze_container
65ms - Module::from_definition
65ms - Module::from_file
65ms - crate_def_map
1ms - parse_macro_query (6 calls)
0ms - raw_items_query (1 calls)
64ms - ???
```
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
2667: Visibility r=matklad a=flodiebold
This adds the infrastructure for handling visibility (for fields and methods, not in name resolution) in the HIR and code model, and as a first application hides struct fields from completions if they're not visible from the current module. (We might want to relax this again later, but I think it's ok for now?)
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2311: See through Macros for SignatureHelp r=matklad a=kjeremy
Note: we meed to skip the trivia filter to make sure that
`covers!(call_info_bad_offset)` succeeds otherwise we exit call_info
too early.
Also the test doesn't pass: `FnCallNode::with_node` always detects
a MacroCall which is obviously wrong.
Fixes#2310
Co-authored-by: kjeremy <kjeremy@gmail.com>
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
Note: we meed to skip the trivia filter to make sure that
`covers!(call_info_bad_offset)` succeeds otherwise we exit call_info
too early.
Also the test doesn't pass: `FnCallNode::with_node` always detects
a MacroCall.
2562: Fix NavigationTarget ranges r=matklad a=edwin0cheng
Fix the issue described in https://github.com/rust-analyzer/rust-analyzer/pull/2544#issuecomment-565572553
This PR change the order for finding `full_range` of `focus_range` in following orders:
1. map both ranges to macro_call
2. map focus range to a token inside macro call, and full range to the whole of macro call
3. map both ranges to the whole of macro call
And fix the corresponding tests and make these tests easily to follow.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2559: Add some granularity to syntax highlighting. r=matklad a=omerbenamram
Hi,
I wanted to start using `rust-analyzer` a bit more frequently - one of the main blockers for me so far was the highlighting.
I just discovered it's possible to override the default colors with `ralsp.<something>` setting without waiting for #2061!
However, the current implementation was lumping a bunch of different tokens into `type` and `literal`.
The golden standard IMO is what Clion is currently doing (and is my current daily driver for rust).
Clion allows users to control the coloring for specific literal kinds, and the default is to distinguish between them (numerics get a different color from strings, and special colors for bytestrings).
I've also splitted the builtin types, which are also allowed to be highlighted speratly.
My goal is to match the default experience I'm getting with clion.
The only blockers now I think is that `rust-analyzer` doesn't corrently infer types in some situations, so the highlighting information is incorrect in those cases.
This is what it looks like so far (with colors overriden to match clion's theme):
If there are any other changes you feel is necessary let me know.
I did leave the default colors to match the current behavior, since I'm not familiar with the colors for this theme, I added some random (different) colors in the test to check that it indeed was working.
Co-authored-by: Omer Ben-Amram <omerbenamram@gmail.com>
