aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide_api
Commit message (Collapse)AuthorAgeFilesLines
...
* | Fix clippy::match_ref_patsAlan Du2019-06-041-6/+6
| |
* | Fix clippy::single_matchAlan Du2019-06-041-4/+3
|/
* don't cache parses twiceAleksey Kladov2019-06-022-7/+29
| | | | | | | | | Before this commit, `Parse`s for original file ended up two times in salsa's db: first, when we parse original file, and second, when we parse macro or a file. Given that parse trees are the worst ofenders in terms of memory, it makes sense to make sure we store them only once.
* collect macro queriesAleksey Kladov2019-06-021-0/+3
|
* add AstDatabaseAleksey Kladov2019-06-021-2/+3
|
* collect types and bodiesAleksey Kladov2019-06-011-0/+4
|
* collect impl source mapsAleksey Kladov2019-06-011-0/+1
|
* don't cache ast_id_to_nodeAleksey Kladov2019-06-011-1/+0
|
* show macro expanded trees in the stats as wellAleksey Kladov2019-06-011-7/+8
|
* Improve goto definition for MBEEdwin Cheng2019-06-012-1/+24
|
* Sort hover results in testsLaurențiu Nicola2019-05-301-2/+8
|
* update ra_ide_api to use builtinsAleksey Kladov2019-05-307-55/+81
|
* :arrow_up: parking_lotAleksey Kladov2019-05-301-1/+0
|
* cancel salsa's validationAleksey Kladov2019-05-301-0/+5
| | | | | | | | | | | | | | | | | | | This small fix should improve rust-analyzer resopnsivness for real-time operations like onEnter handling. Turns out, salsa's validation can take hundreds of milliseconds, and, in case no changes were made, it won't be triggering any queries. Because we check for cancellation in queries, that means that validation is not cancellable! What this PR does is injecting check_canceled checks into validation, by using salsa's event API, which wasn't meant to be used like this, but, hey, it works! Here's the onEnter handling before and after this change: https://youtu.be/7-ffPzgvH7o
* Highlight primitive typesLaurențiu Nicola2019-05-292-42/+55
|
* Merge #1337bors[bot]2019-05-2924-69/+68
|\ | | | | | | | | | | | | | | 1337: Move syntax errors our of syntax tree r=matklad a=matklad I am not really sure if it's a good idea, but `SyntaxError` do not really belong to a `SyntaxTree`. So let's just store them on the side? Co-authored-by: Aleksey Kladov <[email protected]>
| * fix todoAleksey Kladov2019-05-281-3/+0
| |
| * fix typos in mbe testsAleksey Kladov2019-05-2824-68/+70
| |
* | Highlight type names correctlyLaurențiu Nicola2019-05-292-3/+20
|/
* Merge #1334bors[bot]2019-05-271-0/+4
|\ | | | | | | | | | | | | | | 1334: check for cancellation during macro expansion r=matklad a=matklad closes #1331 Co-authored-by: Aleksey Kladov <[email protected]>
| * specifically profile cancellationAleksey Kladov2019-05-271-0/+4
| |
* | make it build againPascal Hertleif2019-05-271-12/+26
| |
* | Disable broken struct field rainbowingPascal Hertleif2019-05-273-23/+7
| |
* | More clever highlighting, incl draft for structsPascal Hertleif2019-05-277-407/+152
| |
* | Hash based on binding name and shadow counterPascal Hertleif2019-05-273-20/+75
| |
* | Semantic highlighting spikePascal Hertleif2019-05-273-35/+345
|/ | | | | | | | | | Very simple approach: For each identifier, set the hash of the range where it's defined as its 'id' and use it in the VSCode extension to generate unique colors. Thus, the generated colors are per-file. They are also quite fragile, and I'm not entirely sure why. Looks like we need to make sure the same ranges aren't overwritten by a later request?
* Colorize Rust code as HTMLAleksey Kladov2019-05-254-152/+131
|
* :arrow_up: rustcAleksey Kladov2019-05-2358-610/+640
|
* profile highlightingAleksey Kladov2019-05-231-0/+3
|
* add union to code_modelAleksey Kladov2019-05-234-0/+11
|
* Improve highlighting of name refsLaurențiu Nicola2019-05-232-9/+168
|
* Move NameRef classification logic out of reference_definitionLaurențiu Nicola2019-05-234-97/+143
|
* Merge #1299bors[bot]2019-05-211-1/+18
|\ | | | | | | | | | | | | | | | | | | | | | | | | 1299: Use ThemeColor and add support for light themes r=matklad a=lnicola Part of #1294. - switch to `ThemeColor` - add light and high contrast theme definitions - highlight control flow keywords and `unsafe` Co-authored-by: Laurențiu Nicola <[email protected]>
| * Address feedbackLaurențiu Nicola2019-05-211-4/+11
| |
| * Use ThemeColor and add support for light themesLaurențiu Nicola2019-05-211-1/+11
| |
* | :arrow_up: instaAleksey Kladov2019-05-211-1/+1
|/
* apply T! macro where it is possibleSergey Parilin2019-05-155-13/+13
|
* expand to syntax nodeAleksey Kladov2019-05-141-1/+1
|
* make AstId untypedAleksey Kladov2019-05-133-5/+5
|
* Merge #1257bors[bot]2019-05-131-1/+2
|\ | | | | | | | | | | | | | | 1257: Implemented tkn! macro for syntax kinds r=matklad a=pasa Implementation of #1248 Co-authored-by: Sergey Parilin <[email protected]>
| * Implemented T! macro for syntax kindsSergey Parilin2019-05-131-1/+2
| |
* | simplifyAleksey Kladov2019-05-121-1/+1
|/
* fill struct fields diagnosticSergey Parilin2019-05-061-1/+122
|
* Profile diagnostics.Marco Groppo2019-05-051-0/+2
|
* Merge #1208bors[bot]2019-05-044-0/+52
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1208: [WIP] Goto for Macro's r=matklad a=Lapz Adds goto definition for macros. Currently only works for macros in the current crate ~~otherwise it panics~~. Proper macro resolution needs to be added for it to resolve macros in other crates. Todo - [X] Allow goto from macro calls - [X] Fix panics - [x] Add tests ![Screen Recording 2019-04-25 at 18 00 24](https://user-images.githubusercontent.com/19998186/56754499-1dd01c00-6785-11e9-9e9a-1e36de70cfa3.gif) Co-authored-by: Lenard Pratt <[email protected]>
| * Added local macro gotoLenard Pratt2019-05-044-0/+52
| |
* | Differentiate Tuple / FnPtr type constructors by cardinalityFlorian Diebold2019-05-041-1/+1
| | | | | | | | | | This is necessary because Chalk (reasonably) expects each 'struct' to know how many type parameters it takes.
* | revert eagarly clean astd mapsAleksey Kladov2019-05-041-6/+1
| | | | | | | | This causes massive slowdown :-(
* | eagarly clean astd mapsAleksey Kladov2019-05-041-0/+6
|/
* Fix hover on the beginning of a nested expressionFlorian Diebold2019-04-282-7/+15
| | | | | | | | | | | | | | | | E.g. in ``` let foo = 1u32; if true { <|>foo; } ``` the hover shows `()`, the type of the whole if expression, instead of the more sensible `u32`. The reason for this was that the search for an expression was slightly left-biased: When on the edge between two tokens, it first looked at all ancestors of the left token and then of the right token. Instead merge the ancestors in ascending order, so that we get the smaller of the two possible expressions.
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-24 21:43:51 +0000