aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge #3591bors[bot]2020-03-156-16/+96
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | 3591: Support local macro_rules r=matklad a=edwin0cheng This PR implement local `macro_rules` in function body, by adding following things: 1. While lowering, add a `MacroDefId` in body's `ItemScope` as a textual legacy macro. 2. Make `Expander::enter_expand` search with given `ItemScope`. 3. Make `Resolver::resolve_path_as_macro` search with `LocalItemScope`. Fix #2181 Co-authored-by: Edwin Cheng <[email protected]>
| * Support local macro_rulesEdwin Cheng2020-03-146-16/+96
| |
* | Merge #3595bors[bot]2020-03-153-11/+80
|\ \ | | | | | | | | | | | | | | | | | | | | | 3595: Fix completion of trait items r=matklad a=flodiebold Trait items should be public by default. Co-authored-by: Florian Diebold <[email protected]>
| * | Fix completion of trait itemsFlorian Diebold2020-03-143-11/+80
|/ / | | | | | | Trait items should be public by default.
* | Merge #3583bors[bot]2020-03-135-37/+33
|\ \ | |/ |/| | | | | | | | | | | | | | | | | 3583: Simplify r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * SimplifyAleksey Kladov2020-03-132-8/+5
| |
| * Simplify testsAleksey Kladov2020-03-131-20/+20
| |
| * Don't use generic DB where a concrete one will doAleksey Kladov2020-03-132-9/+8
|/
*-. Merge #3561 #3577bors[bot]2020-03-1312-45/+122
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3561: feat: add debug code lens r=matklad a=hdevalke Refs #3539 3577: Protect against infinite macro expansion in def collector r=edwin0cheng a=flodiebold Something I noticed while trying to make macro expansion more resilient against errors. There was a test for this, but it wasn't actually working because the first recursive expansion failed. (The comma...) Even with this limit, that test (when fixed) still takes some time to pass because of the exponential growth of the expansions, so I disabled it and added a different one without growth. CC @edwin0cheng Co-authored-by: Hannes De Valkeneer <[email protected]> Co-authored-by: hdevalke <[email protected]> Co-authored-by: Florian Diebold <[email protected]>
| | * Protect against infinite macro expansion in def collectorFlorian Diebold2020-03-131-9/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | There was a test for this, but it wasn't actually working because the first recursive expansion failed. (The comma...) Even with this limit, that test (when fixed) still takes some time to pass because of the exponential growth of the expansions, so I disabled it and added a different one without growth.
| * | Update editors/code/src/config.tshdevalke2020-03-121-1/+0
| | | | | | | | | Co-Authored-By: Veetaha <[email protected]>
| * | fixup! feat: add debug code lensHannes De Valkeneer2020-03-127-19/+26
| | | | | | | | | | | | autodetect vscode-lldb
| * | fixup! feat: add debug code lensHannes De Valkeneer2020-03-123-18/+13
| | | | | | | | | | | | avoid repetition of `--no-run`
| * | fixup! feat: add debug code lensHannes De Valkeneer2020-03-121-2/+1
| | |
| * | Update crates/rust-analyzer/src/main_loop/handlers.rs hdevalke2020-03-121-1/+1
| | | | | | | | | | | | | | | use `Vec::new` instead of `Vec::with_capacity(0)` Co-Authored-By: Veetaha <[email protected]>
| * | feat: add debug code lensHannes De Valkeneer2020-03-118-30/+77
| | | | | | | | | | | | Refs #3539
* | | Merge #3579bors[bot]2020-03-131-10/+10
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3579: Update deps r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | | Update depskjeremy2020-03-131-10/+10
|/ / /
* | | Merge #3576bors[bot]2020-03-137-14/+178
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3576: Parse variadics correctly r=matklad a=matklad closes #3571 bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Parse variadics correctlyAleksey Kladov2020-03-137-14/+178
|/ / | | | | | | closes #3571
* | Merge #3574bors[bot]2020-03-135-6/+62
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3574: Fix completion of HashMap::new r=matklad a=flodiebold The `ty` function in code_model returned the type with placeholders for type parameters. That's nice for printing, but not good for completion, because placeholders won't unify with anything else: So the type we got for `HashMap` was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`, so the `new` method wasn't shown. Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does unify with the impl type. Maybe we should just expose this properly as variables though, i.e. we'd return something like `exists<type, type, type> HashMap<?0, ?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more correctly.) The `ty` function for fields was used for signature help, so there we want placeholders so that it looks nicer, I think. Hence I renamed it to `signature_ty`. Co-authored-by: Florian Diebold <[email protected]>
| * | Fix completion of HashMap::newFlorian Diebold2020-03-135-6/+62
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `ty` function in code_model returned the type with placeholders for type parameters. That's nice for printing, but not good for completion, because placeholders won't unify with anything else: So the type we got for `HashMap` was `HashMap<K, V, T>`, which doesn't unify with `HashMap<?, ?, RandomState>`, so the `new` method wasn't shown. Now we instead return `HashMap<{unknown}, {unknown}, {unknown}>`, which does unify with the impl type. Maybe we should just expose this properly as variables though, i.e. we'd return something like `exists<type, type, type> HashMap<?0, ?1, ?2>` (in Chalk notation). It'll make the API more complicated, but harder to misuse. (And it would handle cases like `type TypeAlias<T> = HashMap<T, T>` more correctly.)
* | Merge #3575bors[bot]2020-03-1314-96/+103
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3575: Restore cargo-fmt gating r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Restore cargo-fmt gatingAleksey Kladov2020-03-134-19/+12
| | |
| * | Move verbose tests out of lineAleksey Kladov2020-03-1310-77/+91
|/ /
* | Merge #3553bors[bot]2020-03-136-11/+108
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3553: Completions do not show for function with same name as mod r=matklad a=JoshMcguigan fixes #3444 I've added a test case in `crates/ra_ide/src/completion/complete_path.rs` which verifies the described behavior in #3444. Digging in, I found that [the module scope iterator](https://github.com/JoshMcguigan/rust-analyzer/blob/ba62d8bd1ce8a68b8d21aaf89ae1ea6787f18366/crates/ra_ide/src/completion/complete_path.rs#L22) only provides the module `z`, and does not provide the function `z` (although if I name the function something else then it does show up here). I thought perhaps the name wasn't being properly resolved, but I added a test in `crates/ra_hir_def/src/nameres/tests.rs` which seems to suggest that it is? I've tried to figure out how to bridge the gap between these two tests (one passing, one failing) to see where the function `z` is being dropped, but to this point I haven't been able to track it down. Any pointers on where I might look for this? Co-authored-by: Josh Mcguigan <[email protected]>
| * | fix issue 3444Josh Mcguigan2020-03-136-11/+108
| |/
* | Merge #3572bors[bot]2020-03-131-0/+34
|\ \ | | | | | | | | | | | | | | | | | | | | | 3572: Add test for completion of unresolved items r=matklad a=matklad Co-authored-by: Aleksey Kladov <[email protected]>
| * | Add test for completion of unresolved itemsAleksey Kladov2020-03-131-0/+34
| | |
* | | Merge #3570bors[bot]2020-03-137-27/+31
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 3570: Remove some TextUnit->usize escapees r=matklad a=CAD97 As spotted during [a review of all uses of `text_unit::TextUnit::to_usize`](https://github.com/rust-analyzer/text_unit/pull/12#issuecomment-598512370). Legitimate uses do remain. Co-authored-by: CAD97 <[email protected]>
| * | Remove some TextUnit->usize escapeesCAD972020-03-137-27/+31
|/ /
* | Merge #3568bors[bot]2020-03-123-0/+12
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3568: Fix completion tests r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Fix completion testsAleksey Kladov2020-03-123-0/+12
|/ /
* | Merge #3566bors[bot]2020-03-1211-62/+73
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3566: Fix docs r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Fix docsAleksey Kladov2020-03-121-2/+3
| | |
| * | Simpler deserializationAleksey Kladov2020-03-126-28/+38
| | |
| * | Make naming more uniformAleksey Kladov2020-03-126-35/+35
|/ /
* | Merge #3543bors[bot]2020-03-1212-43/+150
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3543: Parameter inlay hint separate from variable type inlay? #2876 r=matklad a=slyngbaek Add setting to allow enabling either type inlay hints or parameter inlay hints or both. Group the the max inlay hint length option into the object. - Add a new type for the inlayHint options. - Add tests to ensure the inlays don't happen on the server side Co-authored-by: Steffen Lyngbaek <[email protected]>
| * | Make maxLength nullable againSteffen Lyngbaek2020-03-122-3/+6
| | |
| * | Switch from Vec<InlayKind> to object with propsSteffen Lyngbaek2020-03-1211-85/+41
| | | | | | | | | | | | | | | | | | | | | - Instead of a single object type, use several individual nested types to allow toggling from the settings GUI - Remove unused struct definitions - Install and test that the toggles work
| * | Deduplicate some Inlay definitionsSteffen Lyngbaek2020-03-113-36/+31
| | | | | | | | | | | | - Remove match conversion for InlayKind since we're using remote
| * | Address Issues from GithubSteffen Lyngbaek2020-03-1010-45/+77
| | | | | | | | | | | | | | | | | | | | | - Updated naming of config - Define struct in ra_ide and use remote derive in rust-analyzer/config - Make inlayConfig type more flexible to support more future types - Remove constructor only used in tests
| * | Parameter inlay hint separate from variable type inlay? #2876Steffen Lyngbaek2020-03-1013-34/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add setting to allow enabling either type inlay hints or parameter inlay hints or both. Group the the max inlay hint length option into the object. - Add a new type for the inlayHint options. - Add tests to ensure the inlays don't happen on the server side
* | | Merge #3559bors[bot]2020-03-124-6/+79
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3559: Implement builtin assert! macro r=matklad a=edwin0cheng This PR add a dummy implementation for `assert!` macro, which mainly make `hover` and `goto-def` works on arguments inside it. Co-authored-by: Edwin Cheng <[email protected]>
| * | | Update commentEdwin Cheng2020-03-111-4/+4
| | | | | | | | | | | | | | | | Co-Authored-By: bjorn3 <[email protected]>
| * | | Add test on hoverEdwin Cheng2020-03-111-0/+19
| | | |
| * | | Implement dummy assert macroEdwin Cheng2020-03-114-6/+60
| | | |
* | | | Merge #3556bors[bot]2020-03-121-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3556: settings: rust-analyzer.cargo-watch.enable: clarify that the setting … r=matklad a=matthiaskrgr …enables the cargo-watch command and not "cargo check" Co-authored-by: Matthias Krüger <[email protected]>
| * | | | settings: rust-analyzer.cargo-watch.enable: clarify that the setting enables ↵Matthias Krüger2020-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | the cargo-watch command and not "cargo check"
* | | | | Merge #3564bors[bot]2020-03-1211-458/+722
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3564: Better handling of a few kinds of cargo/clippy diagnostics r=matklad a=kiljacken This was initially supposed to just be a fix for #3433, but I caught a few things that ended up being useful as well. This PR primarily makes us handle multi-edit fix suggestions properly. Instead of just applying the first fix we apply all the parts of the fix in a single action. Second up, this PR handles diagnostics with multiple primary spans, f.x. the unused import diagnostic from rustc: ![image](https://user-images.githubusercontent.com/209321/76531793-03269480-6476-11ea-9180-41c0ea705553.png) The LSP doesn't handle this too well, as it only support a single complete range for each diagnostic, so we get duplicate messages in the problem panel of VSCode: ![image](https://user-images.githubusercontent.com/209321/76531901-29e4cb00-6476-11ea-9746-cd57f8974b85.png) However, I feel like the improved visual aspect in-editor outweighs the duplication in the problem panel. I'm open to not including the second commit if anybody really doesn't like the idea of duplicate diagnostics in the problem pane. Fixes #3433 Fixes #3257 Co-authored-by: Emil Lauridsen <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-30 11:37:07 +0000