2795: Use dummy value for macro file in bulitin macros r=matklad a=edwin0cheng
This PR skip the actual line and column computation for `MacroFile` and return a dummy value instead.
Related to #2794
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
2790: Add test for macro expansion in various expressions r=edwin0cheng a=flodiebold
cc @edwin0cheng
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
2786: Proper handling local in hover r=flodiebold a=edwin0cheng
This PR implement back the `Local` hover information generation, which is fall back to a general case catch previously :
9a44f627be/crates/ra_ide/src/hover.rs (L173-L182)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
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>
2771: Remove the Default impl for SourceRoot r=matklad a=michalt
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>
Co-authored-by: Michal Terepeta <michal.terepeta@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>
2726: Improve profiling output when duration filter is specified r=matklad a=michalt
In particular:
- Use strict inequality for comparisons, since that's what the filter
syntax supports.
- Convert to millis for comparisons, since that's the unit used both
for the filter and when printing.
Now something like `RA_PROFILE='*>0'` will only print things that took
at least 1ms (when rounded to millis).
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Co-authored-by: Michal Terepeta <michal.terepeta@gmail.com>
The `-` turned into a `+` during a refactoring.
The original issue was caused by `Read` resolving wrongly to a trait without
type parameters instead of a struct with one parameter; this only fixes the
crash, not the wrong resolution.
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>
In particular:
- Use strict inequality for comparisons, since that's what the filter
syntax supports.
- Convert to millis for comparisons, since that's the unit used both
for the filter and when printing.
Now something like `RA_PROFILE='*>0'` will only print things that took
at least 1ms (when rounded to millis).
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
2681: cargo-watcher: Resolve macro call site in more cases r=matklad a=kiljacken
This resolves the actual macro call site in a few more cases, f.x. when a macro invokes `compile_error!` (I'm looking at you `ra_hir_def::path::__path`).
Co-authored-by: Emil Lauridsen <mine809@gmail.com>
2668: In-server cargo check watching r=matklad a=kiljacken
Opening a draft now so people can follow the progress, and comment if they spot something stupid.
Things that need doing:
- [x] Running cargo check on save
- [x] Pipe through configuration options from client
- [x] Tests for parsing behavior
- [x] Remove existing cargo watch support from VSCode extension
- [x] Progress notification in VSCode extension using LSP 3.15 `$/progress` notification
- [ ] ~~Rework ra-ide diagnostics to support secondary messages~~
- [ ] ~~Make cargo-check watcher use ra-ide diagnostics~~
~~I'd love some input on whether to try to keep the status bar progress thingy for VSCode? It will require some plumbing, and maintaining yet another rust-analyzer specific LSP notification, which I'm not sure we want to.~~
Fixes#1894
Co-authored-by: Emil Lauridsen <mine809@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>
2657: Omit closure parameters in closure type display strings r=flodiebold a=SomeoneToIgnore
Part of https://github.com/rust-analyzer/rust-analyzer/issues/1946
I wonder, should we display the the closure trait (Fn/FnMut/FnOnce) in inlay hints instead of `|...|` at all?
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
