| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
2730: Add `profile` calls to {Module,Function}::diagnostics r=matklad a=michalt
With this change the output `ra_prof` gives a better indication where
the time is spent. Example output:
```
213ms - publish_diagnostics
213ms - diagnostics
70ms - Module::from_definition
70ms - Module::from_file
132ms - Module::diagnostics
78ms - Function::diagnostics
0ms - body_with_source_map_query (1 calls)
2ms - trait_solve_query (1 calls)
76ms - ???
15ms - Function::diagnostics
0ms - body_with_source_map_query (1 calls)
15ms - trait_solve_query (5 calls)
38ms - Function::diagnostics (51 calls)
8ms - parse_query (1 calls)
```
Signed-off-by: Michal Terepeta <[email protected]>
Co-authored-by: Michal Terepeta <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With this change the output `ra_prof` gives a better indication where
the time is spent. Example output:
```
213ms - publish_diagnostics
213ms - diagnostics
70ms - Module::from_definition
70ms - Module::from_file
132ms - Module::diagnostics
78ms - Function::diagnostics
0ms - body_with_source_map_query (1 calls)
2ms - trait_solve_query (1 calls)
76ms - ???
15ms - Function::diagnostics
0ms - body_with_source_map_query (1 calls)
15ms - trait_solve_query (5 calls)
38ms - Function::diagnostics (51 calls)
8ms - parse_query (1 calls)
```
Signed-off-by: Michal Terepeta <[email protected]>
|
|/
|
|
| |
Signed-off-by: Michal Terepeta <[email protected]>
|
| |
|
| |
|
|\
| |
| | |
fix #2520: change expand_repeat loop stop condition
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
2680: Fix cargo-watcher file urls on windows r=matklad a=kiljacken
Fixes #2676
Co-authored-by: Emil Lauridsen <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
2650: Add macro call support for SourceAnalyzer::type_of r=matklad a=edwin0cheng
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
2674: Reduce visibility r=matklad a=matklad
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | |
|
|/ / / |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 <[email protected]>
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Even though this didn't error, it became clear to me that it was closing
the wrong channel, resulting in the child thread never finishing.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
subprocess
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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]>
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that it's not used as a direct query return value anymore, it doesn't need
to be cheaply cloneable anymore.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Methods should be handled the same, and for items the visibility will be in the
def map.
|
| | | | |
|
| | | | |
|