| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Flag to hide cargo.toml not found error
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
Co-authored-by: Jeremy Kolb <[email protected]>
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
|
| |
| |
| |
| | |
See: https://github.com/microsoft/vscode-languageserver-node/blob/master/protocol/src/protocol.callHierarchy.proposed.ts
|
| | |
|
|\ \
| | |
| | | |
Reject tuple index for missing fields assist
|
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the same change as we did with `crate_def_map` and it does seem
that we mostly spend time in salsa, without recomputing much on
rust-analyzer side.
Example output:
```
233ms - handle_inlay_hints
163ms - get_inlay_hints
163ms - SourceAnalyzer::new
67ms - def_with_body_from_child_node
67ms - analyze_container
67ms - analyze_container
67ms - Module::from_definition
67ms - Module::from_file
67ms - crate_def_map
0ms - parse_macro_query (6 calls)
0ms - raw_items_query (1 calls)
66ms - ???
0ms - crate_def_map (1 calls)
0ms - crate_def_map (1 calls)
96ms - infer
2ms - trait_solve_query (2 calls)
94ms - ???
0ms - body_with_source_map_query (1 calls)
0ms - crate_def_map (1 calls)
[...]
```
Signed-off-by: Michal Terepeta <[email protected]>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
|
| | |
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
2637: Optimize and profile r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | |
|
|/ |
|
| |
|
|
|
|
|
| |
This reverts commit cdc9d682b066b110e0a44e5f8f1c574b38c16ba9, reversing
changes made to 90ef070db3dce0a7acb9cd11d0b0d72de13c9d79.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2617: Remove index resolving from hover r=matklad a=kjeremy
I have left in `HoverResult`'s support for multiple entries because we may still want that at some point.
Per https://github.com/rust-analyzer/rust-analyzer/issues/2542#issuecomment-565238142
Co-authored-by: kjeremy <[email protected]>
|
| | |
|
| |
| |
| |
| | |
We are reasonably precise now to do this.
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|