aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide
Commit message (Collapse)AuthorAgeFilesLines
* Proper emit diagnostic without fixEdwin Cheng2020-01-071-19/+25
|
* Reject tuple index for missing fields assistEdwin Cheng2020-01-071-0/+8
|
* Fix a problem with `Durability` of librariesMichal Terepeta2020-01-061-1/+1
| | | | | | | | | | | | | | | 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]>
* Split `infer` query into two for better profilingMichal Terepeta2020-01-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* Split `crate_def_map` into two methodsMichal Terepeta2020-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
* Drop support for legacy colorizationAleksey Kladov2019-12-313-16/+23
|
* Merge #2667bors[bot]2019-12-291-1/+56
|\ | | | | | | | | | | | | | | 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]>
| * visible_from -> is_visible_fromFlorian Diebold2019-12-271-1/+1
| |
| * Hide completions for private struct fieldsFlorian Diebold2019-12-261-1/+56
| |
* | Omit closure parametersKirill Bulatov2019-12-231-1/+36
|/
* Rudimentary name resolution for local itemsAleksey Kladov2019-12-221-0/+37
|
* Merge #2637bors[bot]2019-12-211-3/+8
|\ | | | | | | | | | | | | | | 2637: Optimize and profile r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Optimize and profileAleksey Kladov2019-12-211-3/+8
| |
* | Remove import source mapAleksey Kladov2019-12-211-2/+0
|/
* Remove imports from hirAleksey Kladov2019-12-212-10/+12
|
* Revert "Merge #2629"Aleksey Kladov2019-12-213-11/+12
| | | | | This reverts commit cdc9d682b066b110e0a44e5f8f1c574b38c16ba9, reversing changes made to 90ef070db3dce0a7acb9cd11d0b0d72de13c9d79.
* Remove import source mapAleksey Kladov2019-12-211-2/+0
|
* Remove hir for importsAleksey Kladov2019-12-212-10/+11
|
* Clippy lintskjeremy2019-12-205-47/+41
|
* Merge #2617bors[bot]2019-12-202-59/+23
|\ | | | | | | | | | | | | | | | | | | 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]>
| * Remove unused importskjeremy2019-12-201-1/+1
| |
| * Remove the index resolution from hoverkjeremy2019-12-201-58/+22
| | | | | | | | We are reasonably precise now to do this.
* | Fix parser for macro call in pattern positionEdwin Cheng2019-12-201-0/+36
|/
* Fix resolve for field init shorthandAleksey Kladov2019-12-203-28/+47
|
* Fix highlighting for field init shorthandAleksey Kladov2019-12-202-5/+4
|
* Improve highlighting testAleksey Kladov2019-12-203-2/+7
|
* Add local functions to bodiesAleksey Kladov2019-12-201-0/+17
|
* Omit default types for hover pop-upsKirill Bulatov2019-12-191-3/+3
|
* Remove TruncateOptions structKirill Bulatov2019-12-192-15/+13
|
* Do not add any new configuration parametersKirill Bulatov2019-12-192-40/+11
|
* Ensure hover shows full type declarationKirill Bulatov2019-12-192-2/+19
|
* Omit default parameter typesKirill Bulatov2019-12-192-20/+77
|
* Merge #2311bors[bot]2019-12-181-10/+33
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Co-authored-by: Jeremy Kolb <[email protected]>
| * cargo fmtJeremy Kolb2019-12-181-1/+3
| |
| * Pass testJeremy Kolb2019-12-181-1/+1
| |
| * WIP: See through Macros for SignatureHelpkjeremy2019-12-181-9/+30
| | | | | | | | | | | | | | | | | | 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.
* | Don't bother with focus range for navigation to localsAleksey Kladov2019-12-182-7/+49
| |
* | Refactor goto tests to always specify textsAleksey Kladov2019-12-181-50/+74
| |
* | Add blank lines for readabilityAleksey Kladov2019-12-181-0/+4
|/
* Merge #2580bors[bot]2019-12-173-3/+3
|\ | | | | | | | | | | | | | | 2580: Fix highlighting token names r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * Fix highlighting token namesAleksey Kladov2019-12-173-3/+3
| |
* | Merge #2562bors[bot]2019-12-172-45/+73
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * Use simpler logic on original_rangeEdwin Cheng2019-12-142-56/+46
| |
| * Re-export Origin to replace ExpansionOriginEdwin Cheng2019-12-141-2/+2
| |
| * Fix original_source find orderEdwin Cheng2019-12-143-47/+85
| |
* | use a module instead of prefixed consts.Omer Ben-Amram2019-12-151-66/+64
| |
* | introduce named constants for highlighting tag names.Omer Ben-Amram2019-12-151-37/+67
| |
* | Merge #2559bors[bot]2019-12-153-17/+27
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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): ![image](https://user-images.githubusercontent.com/2467993/70848219-ccd97900-1e76-11ea-89e1-2e467cfcc9fb.png) 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 <[email protected]>
| * | fixed rainbow-highlighting testOmer Ben-Amram2019-12-151-0/+2
| | |
| * | removed `type.alias`Omer Ben-Amram2019-12-142-14/+18
| | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 20:03:29 +0000