7465: Only hide parameter hints for path, field and methodcall expressions r=SomeoneToIgnore a=Veykril
Doing this check for other expressions makes little sense to me.
Fixes#7458
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7457: Add no-buffering file logging and wait for a debugger option. r=vsrs a=vsrs
Adds two command line flags: `--no-buffering` and `--wait-dbg`.
Not sure if someone else needs this, but personally I found both flags extremely useful trying to figure out why RA does not work with Visual Studio. Or better to say why Visual Studio does not work with RA.
Co-authored-by: vsrs <vit@conrlab.com>
7433: Support Macro v2 in mbe r=jonas-schievink a=edwin0cheng
Added `mbe::MacroDef` for Macro v2.
cc @jonas-schievink
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7426: Create all `ModuleId`s through a `DefMap` method r=jonas-schievink a=jonas-schievink
`ModuleId` needs to be able to represent blocks, and only the
associated `DefMap` will know how to construct that `ModuleId`
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7399: Make `ModuleId`'s `krate` field private and audit uses r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Detail should be rendered as shtort one line, just dumping fn header
there is not useful, despite the fact that TS does this.
The fact that this is a function should be indicated by the icon, the
same goes for pub/const/async etc qualitfiers
name is already present in the lable (and arg list should be a part of
that, as in idea)
But the return type is the small genuinerlly useful bit of info we can show here
7310: Add assist: add lifetime to type r=matklad a=bnjjj
close#7200
7395: Obtain `ModuleId`'s `DefMap` through a method r=jonas-schievink a=jonas-schievink
Once `ModuleId` can represent modules inside block expressions, this will be required in order to obtain the correct `DefMap`. Otherwise existing code might use a `LocalModuleId` from the wrong `DefMap` and cause a panic.
bors r+
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7353: Add LifetimeParam and ConstParam to CompletionItemKind r=matklad a=Veykril
Adds `LifetimeParam` and `ConstParam` to `CompletionItemKind` and maps them both to `TypeParam` in the protocol conversion as there are no equivalents, so nothing really changes there.
`ConstParam` could be mapped to `Const` I guess but I'm split on whether that would be better?
Additions were solely inspired by (the single) test output for const params.
Also sorts the variants of `CompletionItemKind` and its to_proto match.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7386: Handle box with allocator r=flodiebold a=tweksteen
In 1.49.0, the definition of Box was modified to support an optional
Allocator[1]. Adapt the parsing of the `box` keyword to supply the
expected number of parameters to the constructor.
[1] f288cd2e17Fixes: #6956
Co-authored-by: Thiébaud Weksteen <tweek@google.com>
In 1.49.0, the definition of Box was modified to support an optional
Allocator[1]. Adapt the parsing of the `box` keyword to supply the
expected number of parameters to the constructor.
[1] f288cd2e17
7348: Fix broken link in intra-doc r=edwin0cheng a=sasurau4
Fix#5546
The intra-doc link doesn't work fine for trait associated method.
Co-authored-by: Daiki Ihara <sasurau4@gmail.com>
7387: Refactor build script specific data r=edwin0cheng a=edwin0cheng
It refactors for separating logic for build script specific data.
bors r+
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7375: Add support for running name resolution in block expressions r=jonas-schievink a=jonas-schievink
This adds a `block_def_map` query that runs the name resolution algorithm on a block expression, and returns a `DefMap` that stores links to the parent `DefMap` (either the containing block or the crate-level `DefMap`). Blocks with no inner items return the parent's `DefMap` as-is, to avoid creating unnecessarily long `DefMap` chains.
Path resolution is updated to recurse into the parent `DefMap` after looking up a path in the original `DefMap`.
I've added a few new tests for this, but outside of those this isn't used yet.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7359: ItemTree: store a mapping from blocks to inner items r=jonas-schievink a=jonas-schievink
To do name resolution within block expressions, we need to know which inner items are located inside each block expression. This adds such a mapping to `ItemTree`, replacing the previous one, which was seemingly unused other than to access all the inner items.
This also assigns `AstId`s to block expressions, which is needed to store the mapping in salsa.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7341: Fix warnings when running `cargo doc --document-private-items` r=Veykril a=jyn514
These were the warnings previously:
<details>
```
warning: could not parse code block as Rust code
--> crates/stdx/src/lib.rs:137:9
|
137 | /// ∀ x in slice[..idx]: pred(x)
| _________^
138 | | /// && ∀ x in slice[idx..]: !pred(x)
| |____^
|
= note: error from rustc: unknown start of token: \u{2200}
warning: 1 warning emitted
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= note: `#[warn(broken_intra_doc_links)]` on by default
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: 2 warnings emitted
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= note: `#[warn(broken_intra_doc_links)]` on by default
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: 2 warnings emitted
```
</details>
This does *not* fix the following warning, because it is actually rust
code and rustdoc is being over eager:
```
warning: Rust code block is empty
--> crates/parser/src/grammar.rs:16:5
|
16 | //! ```
| _____^
17 | | //! // test function_with_zero_parameters
18 | | //! // fn foo() {}
19 | | //! ```
| |_______^
|
help: mark blocks that do not contain Rust code as text
|
16 | //! ```text
| ^^^^^^^
```
https://github.com/rust-lang/rust/pull/79816 should make this
configurable so the warning can be `allow`ed.
Co-authored-by: Joshua Nelson <jyn514@gmail.com>
These were the warnings previously:
```
warning: could not parse code block as Rust code
--> crates/stdx/src/lib.rs:137:9
|
137 | /// ∀ x in slice[..idx]: pred(x)
| _________^
138 | | /// && ∀ x in slice[idx..]: !pred(x)
| |____^
|
= note: error from rustc: unknown start of token: \u{2200}
warning: 1 warning emitted
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= note: `#[warn(broken_intra_doc_links)]` on by default
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: 2 warnings emitted
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= note: `#[warn(broken_intra_doc_links)]` on by default
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: unresolved link to `package`
--> crates/base_db/src/input.rs:181:15
|
181 | /// it's [package].name, can be different for other project types or even
| ^^^^^^^ no item named `package` in scope
|
= help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
warning: 2 warnings emitted
```
This does *not* fix the following warning, because it is actually rust
code and rustdoc is being over eager:
```
warning: Rust code block is empty
--> crates/parser/src/grammar.rs:16:5
|
16 | //! ```
| _____^
17 | | //! // test function_with_zero_parameters
18 | | //! // fn foo() {}
19 | | //! ```
| |_______^
|
help: mark blocks that do not contain Rust code as text
|
16 | //! ```text
| ^^^^^^^
```
https://github.com/rust-lang/rust/pull/79816 should make this
configurable so the warning can be `allow`ed.
7340: Remove obsolete RangeInfo usage in references r=Veykril a=Veykril
Didn't even realize these were only here for renaming as well!
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7336: Rename `CrateDefMap` to `DefMap` r=matklad a=jonas-schievink
I propose handling local items by computing a `DefMap` for every block expression, using the regular (early) name resolution algorithm. The result of that will be a `DefMap` that has a reference to the parent `DefMap`, which is either the one computed for the containing block expression, or the crate's root `DefMap`. Name resolution will fall back to a name in the parent `DefMap` if it cannot be resolved in the inner block.
The `DefMap`s computed for block expressions will go through a separate query that can be garbage-collected much more aggressively, since these `DefMap`s should be cheap to compute and are never part of a crate's public API.
The first step towards that is to make `CrateDefMap` not specific to crates anymore, hence this rename (if this plans sounds reasonable).
cc https://github.com/rust-analyzer/rust-analyzer/issues/7325 and https://github.com/rust-analyzer/rust-analyzer/issues/1165
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7339: Delete optional arg for inline attr and add doc alias attr completion r=lnicola a=bnjjj
close#7167
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
7331: shrink_to_fit `TokenMap`'s backing storage r=jonas-schievink a=jonas-schievink
Reduces `HygieneFrameQuery`'s memory usage by like 10 MB or so
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7291: Wrap remaining self/super/crate in Name{Ref} r=matklad a=Veykril
That should be the remaining special casing for `self` 🎉
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
I've noticed a bunch of "main loop too long" warnings in console when
typing in Cargo.toml. Profiling showed that the culprit is `rustc
--print cfg` call.
I moved it to the background project loading phase, where it belongs.
This highlighted a problem: we generally use single `cfg`, while it
really should be per crate.
7276: Remove map module from la-arena public API r=lnicola a=arzg
It’s unlikely that more items will be added to the module, so it’s simpler for users if `ArenaMap` is re-exported and the module made private.
This doesn’t compile for the same reason that #7275 doesn’t:
> This pull request doesn’t compile because dependencies on la-arena go through crates.io, so existing dependencies on the crate are referencing an old version. As such, this PR will only compile once a new la-arena version has been published.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
7211: Fixed expr meta var after path colons in mbe r=matklad a=edwin0cheng
Fixes#7207
Added `L_DOLLAR` in `ITEM_RECOVERY_SET` , but I don't know whether it is a good idea.
r? @matklad
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7257: vfs documentation r=matklad a=arnaudgolfouse
This documents every item in the `vfs` crate, except for a few private, windows-specific items.
Co-authored-by: Arnaud <arnaud.golfouse@free.fr>
7110: Deduplicate macros when offering completion r=matklad a=AdnoC
Closes https://github.com/rust-analyzer/rust-analyzer/issues/7081
When iterating over the names within the `hir_def::resolver::Scope` for a module, track what macros are in the `hir_def::item_scope::ItemScope::legacy_macros` collection for the module. When iterating over names from the prelude, do not proccess the name if it had been in the `legacy_macros` collection.
This is implemented with a `FxHashSet` in the `Scope::process_names` function that is populated when iterating over `legacy_macros` and checked when iterating over the prelude.
Alternative implementation could instead query the `legacy_macros` `FxHashMap` directly when processing names in the prelude.
Also, I'd like to add a test for this, but I'm not sure where it could be added.
Co-authored-by: AdnoC <adam.r.cutler@gmail.com>
7260: Render Fn* trait objects and impl types as rust does r=matklad a=Veykril
Also fixes raw ptr impl types being rendered ambiguously with multiple predicates.
This moves out the `FamousDefs::Fixture` into its own file as well, cause I figured it is big enough to get its own file at this point + we also get highlighting this way when editing it.
Fixes#3012
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7220: same level folder rename for will_rename_files r=kjeremy a=ShuiRuTian
use tricky way to support folder rename.
Another step after #7009 and for #4471
Co-authored-by: ShuiRuTian <158983297@qq.com>
Co-authored-by: Song Gao <158983297@qq.com>
7051: Check dbg! macro in tidy_test r=matklad a=edwin0cheng
Same as `check_todo` but for dbg! macro
r? @matklad
7219: Refactor rename name checking r=matklad a=Veykril
Improves the user facing error messages a bit and prevents renaming to `_` when the name is referenced as this would change source to not compile anymore since `_` is only a pattern, not a proper identifier.
7245: Encourage gifs r=matklad a=matklad
bors r+
🤖
7246: Unfreeze cargo_metadata r=matklad a=kjeremy
It now pulls in a newer version of semver-parser.
This does add a dependency on `cargo-platform` in the interest of correctness.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Co-authored-by: kjeremy <kjeremy@gmail.com>
7235: Postfix completions like ifl now works with references r=Veykril a=Maan2003
Closes#7230
Co-authored-by: Manmeet <manmeetmann2003@gmail.com>
Co-authored-by: Manmeet Maan <manmeetmann2003@gmail.com>
7218: Fix typos r=Veykril a=regexident
Apart from the very last commit on this PR (which fixes a public type's name) all changes are non-breaking.
Co-authored-by: Vincent Esche <regexident@gmail.com>
After we started reporting progress when running cargo check during
loading, it is possible to crash the client with two identical progress
tokens.
This points to a deeper issue: we might be running several cargo checks
concurrently, which doesn't make sense.
This commit linearizes all workspace fetches, making sure no updates are
lost.
As an additional touch, it also normalizes progress & result reporting,
to make sure they stand in sync.
6238: Split punctuation semantic highlighting up into more tags r=matklad a=Veykril
Open question would be the name of the delimiter modifiers. I chose them this was as I see them this way but from what I remember people tend to mix the names however they like. So maybe using `delimSquare`, `delimCurly`, `delimRound` would be better. That would also go well with `angle` becoming `delimAngle`?
Closes#6152
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6980: Implement to support intra-doc link r=matklad a=sasurau4
Helps with #6168
This PR is very limited implementation to support intra-doc. It only support links indicate same file function.
I want someone to feedback me about this implementation. If the approach is good, I will continue this PR to support other symbols like enum and struct.
Co-authored-by: Daiki Ihara <sasurau4@gmail.com>
7224: Remove unnecessary allocation when checking whether to hide argument name hint r=jhpratt a=jhpratt
The case-insensitive prefix/suffix check can be performed
character-by-character. This allows the check to be done without having
to allocate a new string. As a side effect, it's also no longer
necessary to convert the entire string to lowercase, as it's done as
needed. As the only case equality we're handling is ASCII, this
operation can be further optimized by using byte equality, rather than
character equality.
cc @SomeoneToIgnore, as it's an update on my PR from yesterday.
Co-authored-by: Jacob Pratt <jacob@jhpratt.dev>
The case-insensitive prefix/suffix check can be performed
character-by-character. This allows the check to be done without having
to allocate a new string. As a side effect, it's also no longer
necessary to convert the entire string to lowercase, as it's done as
needed. As the only case equality we're handling is ASCII, this
operation can be further optimized by using byte equality, rather than
character equality.
7145: Proper handling $crate Take 2 [DO NOT MERGE] r=edwin0cheng a=edwin0cheng
Similar to previous PR (#7133) , but improved the following things :
1. Instead of storing the whole `ExpansionInfo`, we store a similar but stripped version `HygieneInfo`.
2. Instread of storing the `SyntaxNode` (because every token we are interested are IDENT), we store the `TextRange` only.
3. Because of 2, we now can put it in Salsa.
4. And most important improvement: Instead of computing the whole frames every single time, we compute it recursively through salsa: (Such that in the best scenario, we only need to compute the first layer of frame)
```rust
let def_site = db.hygiene_frame(info.def.file_id);
let call_site = db.hygiene_frame(info.arg.file_id);
HygieneFrame { expansion: Some(info), local_inner, krate, call_site, def_site }
```
The overall speed compared to previous PR is much faster (65s vs 45s) :
```
[WITH old PR]
Database loaded 644.86ms, 284mi
Crates in this dir: 36
Total modules found: 576
Total declarations: 11153
Total functions: 8715
Item Collection: 15.78s, 91562mi
Total expressions: 240721
Expressions of unknown type: 2635 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 865
Inference: 49.84s, 250747mi
Total: 65.62s, 342310mi
rust-analyzer -q analysis-stats . 66.72s user 0.57s system 99% cpu 1:07.40 total
[WITH this PR]
Database loaded 665.83ms, 284mi
Crates in this dir: 36
Total modules found: 577
Total declarations: 11188
Total functions: 8743
Item Collection: 15.28s, 84919mi
Total expressions: 241229
Expressions of unknown type: 2637 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 868
Inference: 30.15s, 135293mi
Total: 45.43s, 220213mi
rust-analyzer -q analysis-stats . 46.26s user 0.74s system 99% cpu 47.294 total
```
*HOWEVER*, it is still a perf regression (35s vs 45s):
```
[WITHOUT this PR]
Database loaded 657.42ms, 284mi
Crates in this dir: 36
Total modules found: 577
Total declarations: 11177
Total functions: 8735
Item Collection: 12.87s, 72407mi
Total expressions: 239380
Expressions of unknown type: 2643 (1%)
Expressions of partially unknown type: 2064 (0%)
Type mismatches: 868
Inference: 22.88s, 97889mi
Total: 35.74s, 170297mi
rust-analyzer -q analysis-stats . 36.71s user 0.63s system 99% cpu 37.498 total
```
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
This leaks a lot of LSP details into ide layer, which we want to avoid:
c9cec381bc/docs/dev (lsp-independence)
Additionally, all what this infra does is providing a toggle for
auto-import completion, but we already have one!
7181: Document project_model::PackageData and project_model::TargetData r=arnaudgolfouse a=arnaudgolfouse
This PR adds some documentation for the `project_model` crate.
Some of the field descriptions were taken directly from their `cargo_metadata` counterpart :
- `PackageData` -> `cargo_metadata::Package`
- `TargetData` -> `cargo_metadata::Target`
Co-authored-by: Arnaud <arnaud.golfouse@free.fr>
Rather than eagerly converting JSON, we losslessly keep it as is, and
change the shape of user-submitted data at the last moment.
This also allows us to remove a bunch of wrong Defaults
7176: Attribute completion r=matklad a=FlowerBOII
Solve #7167.
I removed the optional args for the attributes ```deprecated```, ```must_use``` and ```should_panic```.
I also updated their respective tests.
Please let me know if I missed something.
Co-authored-by: FlowerBOII <42295129+FlowerBOII@users.noreply.github.com>
7140: Store trait associated items in fst r=matklad a=SomeoneToIgnore
Store imported traits' associated function/methods and constants into `ImportMap.fst` and pefrorm the imports search on them.
This is a first step towards trait autoimport during completion functionality, the way I see it, after this PR, only a few major things are left to be done:
* store all traits' assoc items into fst, not only the ones in scope, as we do now. Any code pointers on how to do this are welcome 😄
* adjust a few modules in completions crate (`dot.rs`, `qualified_path.rs` at least) to query the import map, reusing the `import_assets` logic heavily
==
With the current import and autoimport implementations, it looks like for a single query, we're either interested in either associated items lookup or in all other `fst` contents lookup, but never both simultaneously.
I would rather not split `fst` in two but add another `Query` parameter to separate those, but let me know if you have any ideas.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
7131: Created an assist for inlining a function's body into its caller r=matklad a=Michael-F-Bryan
This introduces an `inline_function` assist which will convert code like this:
```rust
fn add(a: u32, b: u32) -> u32 { a + b }
fn main() {
let x = add<|>(1, 2);
}
```
Into something like this:
```rust
fn add(a: u32, b: u32) -> u32 { a + b }
fn main() {
let x = {
let a = 1;
let b = 2;
a + b
};
}
```
Fixes#6863.
Co-authored-by: Michael-F-Bryan <michaelfbryan@gmail.com>
7162: Introduce queries to avoid problems when performing completion for enums with many variants r=matklad a=danielframpton
This change introduces two new queries to compute:
1) attributes for all variants of an enum, and
2) attributes for all fields of a variant.
The purpose of this change is to avoid the current n^2 behavior when rendering completion for variants (which prevents completion for enums with large numbers of variants).
Co-authored-by: Daniel Frampton <Daniel.Frampton@microsoft.com>
1) the set of attributes for all variants of an enum, and
2) the set of attributes for all fields of a variant.
This avoids the current n^2 behavior when rendering completion for variants, which
prevents completion for enums with large numbers of variants.
7160: Get `hir::Function` return type r=flodiebold a=arnaudgolfouse
Hello !
As said in #7158, I noticed that `hir::Function` has no direct way of getting the return type, so this PR adds this functionality.
Co-authored-by: Arnaud <arnaud.golfouse@free.fr>
7147: ssr: Allow replacing expressions with statements r=davidlattimore a=MarijnS95
Depends on #6587
Until that is merged, the diff is https://github.com/MarijnS95/rust-analyzer/compare/stmt..replace-expr-with-stmt
---
Now that statements can be matched and replaced (#6587) some usecases require expressions to be replaced with statements as well. This happens when something that can ambiguously be an expression or statement like `if` and loop blocks appear in the last position of a block, as trailing expression. In this case a replacement pattern of the form `if foo(){$a();}==>>$a();` will only substitute `if` blocks in the list of statements but not if they (implicitly) end up in the trailing expression, where they are not wrapped by an EXPR_STMT (but the pattern and template are, as parsing only succeeds for the `stmt ==>> stmt` case).
Instead of adding two rules that match an expression - and emit duplicate matching errors - allow the template for expressions to be a statement if it fails to parse as an expression.
---
Another gross change that does not seem to break any tests currently, but perhaps a safeguard should be added to only allow this kind of replacement in blocks by "pushing" the replacement template to the statement list and clearing the trailing expression?
CC @davidlattimore
Co-authored-by: Marijn Suijten <marijn@traverseresearch.nl>
This is done by adding a `ret_type` method to `hir::Function`.
I followed `assoc_fn_params` convention by creating a new `RetType` type,
that contains the actual return type accessible via a `ty` method.
6587: SSR: Support statement matching and replacing r=davidlattimore a=MarijnS95
For #3186
Hi!
This is a smaller initial patchset that came up while working on support for statement lists (and my first time working on RA 😁). It has me stuck on trailing semicolons for which I hope to receive some feedback. Matching (and replacing) `let` bindings with a trailing semicolon works fine, but trying to omit these (to make patterns more ergonomic) turns out more complex than expected.
The "optional trailing semicolon solution" implemented in this PR is ugly because `Matcher::attempt_match_token` should only consume a trailing `;` when parsing `let` bindings to prevent other code from breaking. That at the same time has a nasty side-effect of `;` ending up in the matched code: any replacements on that should include the trailing semicolon as well even if it was not in the pattern. A better example is in the tests:
3ae1649c24/crates/ssr/src/tests.rs (L178-L184)
The end result to achieve is (I guess) allowing replacement of let bindings without trailing semicolon like `let x = $a ==>> let x = 1` (but including them on both sides is still fine), and should make replacement in a macro call (where `foo!(let a = 2;)` for a `$x:stmt` is invalid syntax) possible as well. That should allow to enable/fix these tests:
3ae1649c24/crates/ssr/src/tests.rs (L201-L214)
A possible MVP of this PR might be to drop this optional `;' handling entirely and only allow an SSR pattern/template with semicolons on either side.
Co-authored-by: Marijn Suijten <marijn@traverseresearch.nl>
Now that statements can be matched and replaced (#6587) some usecases
require expressions to be replaced with statements as well. This happens
when something that can ambiguously be an expression or statement like
`if` and loop blocks appear in the last position of a block, as trailing
expression. In this case a replacement pattern of the form `if
foo(){$a();}==>>$a();` will only substitute `if` blocks in the list of
statements but not if they (implicitly) end up in the trailing
expression, where they are not wrapped by an EXPR_STMT (but the pattern
and template are, as parsing only succeeds for the `stmt ==>> stmt`
case).
Instead of adding two rules that match an expression - and emit
duplicate matching errors - allow the template for expressions to be a
statement if it fails to parse as an expression.
7068: Add VSCode command to view the hir of a function body r=theotherphil a=theotherphil
Will fix https://github.com/rust-analyzer/rust-analyzer/issues/7061. Very rough initial version just to work out where I needed to wire everything up.
@matklad would you be happy merging a hir visualiser of some kind? If so, do you have any thoughts on what you'd like it show, and how?
I've spent very little time on this thus far, so I'm fine with throwing away the contents of this PR, but I want to avoid taking the time to make this more polished/interactive/useful only to discover that no-one else has any interest in this functionality.
Co-authored-by: Phil Ellison <phil.j.ellison@gmail.com>
7115: Migrate HasSource::source to return Option r=matklad a=nick96
I've made a start on fixing #6913 based on the provided work plan, migrating `HasSource::source` to return an `Option`. The simple cases are migrated but there are a few that I'm unsure exactly how they should be handled:
- Logging the processing of functions in `AnalysisStatsCmd::run`: In verbose mode it includes the path to the module containing the function and the syntax range. I've handled this with an if-let but would it be better to blow up here with `expect`? I'm not 100% on the code paths but if we're processing a function definition then the source should exist.
I've handled `source()` in all code paths as `None` being a valid return value but are there some cases where we should just blow up? Also, all I've done is bubble up the returned `None`s, there may be some places where we can recover and still provide something.
Co-authored-by: Nick Spain <nicholas.spain@stileeducation.com>
Co-authored-by: Nick Spain <nicholas.spain96@gmail.com>
7133: Proper handling $crate and local_inner_macros r=jonas-schievink a=edwin0cheng
This PR introduces `HygineFrames` to store the macro definition/call site hierarchy in hyginee and when resolving `local_inner_macros` and `$crate`, we use the token to look up the corresponding frame and return the correct value.
See also: https://rustc-dev-guide.rust-lang.org/macro-expansion.html#hygiene-and-hierarchies
fixe #6890 and #6788
r? @jonas-schievink
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7130: Add extract_assignment assist r=Jesse-Bakker a=Jesse-Bakker
Add extract-assignment assist (#7006).
Assist is for now only implemented on if/match-statements where the assigment is the last statement in every block,
as for other cases, one would have to check whether the assignment has effects on the rest of the block and
extract a temporary variable for it in the block.
Co-authored-by: Jesse Bakker <github@jessebakker.com>
The `LifetimeParam` and `Local` variants use `source()` to find their
range. Now that `source()` returns an `Option` we need to handle the
`None` case.
In #6901 some special case handling for proc-macros was introduced to
prevent panicing as they have no AST. Now the new HasSource::source
method is used that returns an option.
Generally this was a pretty trivial change, the only thing of much
interest is that `hir::MacroDef` now implements `TryToNav` not `ToNav`
as this allows us to handle `HasSource::source` now returning an option.
Added the error message to the doc for the UnresolvedProcMacro
diagnostic, explaining that either enabling the procMacro setting
or disabling this diagnostic should make the warnings go away.
7116: Fix deep syntax tree bug generated by proc-macro r=jonas-schievink a=edwin0cheng
This PR fixed a bug from `semver-parser` and `pest_derive` crates which generate a very deep syntax tree such that serde reject to de-serialize. To fix this bug, we disabled recursion limit in `serde` (by calling [`Deserializer::disable_recursion_limit`](https://docs.rs/serde_json/1.0.61/serde_json/struct.Deserializer.html#method.disable_recursion_limit))
I have a feeling that we still need some way to protect against bad proc-macro generating huge syntax node, but I have no idea right now.
r? @jonas-schievink
Fixes#7103
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7102: Fix completion of Default struct update syntax r=Veykril a=nick96
Previously the inserted text was always `..Default::default()` which ends up as `...Default::default()`
if `.` was typed. Now checks if the current token is `.` and inserts `.Default::default()`
if it is, so `..Default::default()` is correctly completed.
I think there's probably a better way to implement this context aware completion because I've seen it in other parts of rust-analyzer as a user but I'm not sure how to do it.
Fixes#6969
Co-authored-by: Nick Spain <nicholas.spain@stileeducation.com>
7071: Pass --all-targets to "cargo check" when discovering external resources r=matklad a=WasabiFan
There is a repro case and background in the linked issue.
In short, the goal of this MR is to allow rust-analyzer to discover proc-macros which come from your tests (including, most importantly, dev-dependencies).
By default, `cargo check` implies the equivalent of `--lib --bins`, meaning it'll check your libraries and binaries -- but not tests! This means proc-macros (or, I guess, build scripts as well) weren't discovered by rust-analyzer if they came from tests.
One solution would be to manually add `--lib --bins --tests` (i.e., just augment the effective options to include tests). However, in this MR, I threw in `--all-targets`, which [according to the docs](https://doc.rust-lang.org/cargo/commands/cargo-check.html#target-selection) implies `--benches --examples` too. I have absolutely no idea what repercussions that will have on rust-analyzer for other projects, nor do I know if it's a problem that build scripts will now be discovered for tests/examples/benches. But I am not aware of a reason you _wouldn't_ want to discover these things in your examples too.
I think the main drawback of this change is that it will likely slow down the `cargo check`. At a minimum, it'll now be checking your tests _and_ their dependencies. The `cargo check` docs also say that including `--tests` as I have here may cause your lib crate to be built _twice_, once for the normal target and again for unit tests. My reading of that caveat suggests that "building twice" means it's built once for the tests _inside_ your lib, with a test profile, and again for any consumers of your lib, now using a normal release profile or similar. This doesn't seem surprising.
Very minor caveat: `--tests` will not include tests within a binary if it has `test = false` set in `Cargo.toml`. (I discovered this manually by trial-and-error, but hey, it actually says that in the docs!) This is likely not an issue, but _does_ mean that if you are -- for whatever reason -- disabling tests like that and then manually specifying `cargo test --package <...> --bin <...>` to run them, rust-analyzer will remain unaware of proc-macros in your tests.
I have confirmed this fixes the original issue in my sandbox example linked in #7034 and in my own project in which I originally discovered this. I've left it configured as my default RA language server and will report back if I notice any unexpected side-effects.
Fixes#7034
Co-authored-by: Kaelin Laundry <wasabifan@outlook.com>
In an attempt to fix#6052 and #4249 this attempts to detect
if rustfmt is a rustup proxy which isn't installed, and reports
the error message to the user for them to fix.
In theory this ought to be memoised but for now it'll do as-is.
Future work might be to ask the user if they would like us to
trigger the installation (if possible).
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Previously the inserted text was always `..Default::default()` which ends up as `...Default::default()`
if `.` was typed. Now checks if the current token is `.` and inserts `.Default::default()`
if it is, so `..Default::default()` is correctly completed.
Fixes#6969
7083: Refactor mbe parsing code r=edwin0cheng a=edwin0cheng
Inspire by #5426 , this PR refactor out the parsing code such that it only parsed on `mbe::Rule`, but not on invocations.
However, it just improve the overall performance unnoticeablely :(
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7064: Ignore qualifiers when doing autoimport completions lookup r=lnicola a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/6918#issuecomment-748511151 and the PR itself.
Tweaks the `import_map` query api to be more flexible with the ways to match against the import path and now fuzzy imports search in names only.
This had improved the completion speed for me locally in ~5 times for `fuzzy_completion` span time, but please recheck me here.
IMO we're fast and presice enough now, so I've added the modules back to the fuzzy search output.
Also tweaks the the expect tests to display functions explicitly, to avoid confusing "duplicate" results.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
7075: format-postfix completion takes format instead of fmt r=lnicola a=Veykril
See https://github.com/rust-analyzer/rust-analyzer/issues/6843
this brings it back in line with the documentation
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7050: Ignore third punct when matching for 2-composite punct in mbe r=jonas-schievink a=edwin0cheng
Fixes#6692
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7047: Add force_show_panics flag for proc-macro bridge r=jonas-schievink a=edwin0cheng
https://github.com/rust-lang/rust/pull/75082 and https://github.com/rust-lang/rust/pull/76292 added a new flag in `proc_macro::Bridge` such that the ABI was changed. These ABI changing are the reason of some weird panics which caused #6880 and maybe related to the panic mentioned in #6820.
These changes are landed on rust stable 1.48 so I think it is okay to apply it now.
fixes#6880
r @jonas-schievink
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
Assist vs UnresolvedAssist split doesn't really pull its weight. This
is especially bad if we want to include `Assist` as a field of
diagnostics, where we'd have to make the thing generic.
7030: Support labels in reference search r=matklad a=Veykril
Implements general navigation for labels, goto def, rename and gives labels their own semantic highlighting class.
Fixes#6966
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7010: Update ungrammar for const block patterns r=matklad a=Veykril
Fixes#6848
Adds const blocks and const block patterns to the AST and parses them.
Blocked on https://github.com/rust-analyzer/ungrammar/pull/17/, will merge that PR there once this one gets the OK so I can remove the local ungrammar dependency path and fix the Cargo.lock.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Avoid mutation of snapshot's config -- that's spooky action at a
distance. Instead, copy it over to a local variable.
This points out a minor architecture problem, which we won't fix right
away.
Various `ide`-level config structs, like `AssistConfig`, are geared
towards one-shot use when calling a specific methods. On the other
hand, the large `Config` struct in `rust-analyzer` is a long-term
config store.
The fact that `Config` stores `AssistConfig` is accidental -- a better
design would probably be to just store `ConfigData` inside `Config`
and create various `Config`s on the fly out of it.
6960: Show enum variant on Self qualified paths r=matklad a=Veykril
Fixes first part of #6549Fixes#6550
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7000: Store invocation site for eager macros r=edwin0cheng a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6992
r? @edwin0cheng
I'm not sure if this is totally correct, it looks like we create **two** `EagerCallLoc`s per macro invocation, one for the arguments (?), and one for the actual macro call. I gave both the same `AstId`, hopefully that's correct.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6964: Add full pattern completions for Struct and Variant patterns r=matklad a=Veykril
Just gonna call it full pattern completion as pattern completion is already implemented in a sense by showing idents in pattern position. What this does is basically complete struct and variant patterns where applicable(function params, let statements and refutable pattern locations).
This does not replace just completing the corresponding idents of the structs and variants, instead two completions are shown for these, a completion for the ident itself and a completion for the pattern(if the pattern make sense to be used that is). I figured in some cases one would rather type out the pattern manually if it has a lot of fields but you only care about one since this completion would cause one more work in the end since you would have to delete all the extra matched fields again.
These completions are tagged as `CompletionKind::Snippet`, not sure if that is the right one here.
<details>
<summary>some gifs</summary>
</details>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
* simplify code
* correctly handle crate roots and mod.rs files (nested inline modules
are still mishandled)
* make sure that new text contains a trailing newline
6993: Clean up descriptions for settings r=matklad a=rherrmann
Use two consecutive newlines (`\n\n`) to actually continue text on a
new line.
Use proper markup to reference related settings.
Consistently format references to files, command line arguments, etc.
as `code`. Format mentions of UI elements in _italic_.
Fix typos, add missing full-stops, add missing default values.
Co-authored-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Use two consecutive newlines (`\n\n`) to actually continue text on a
new line.
Use proper markup to reference related settings.
Consistently format references to files, editor commands, command line
arguments, files, etc. as `code`.
Fix typos, add missing full-stops, add missing default values.
6982: Remove parentheses when inverting `!(cond)` r=matklad a=Jesse-Bakker
Followup to #6894
When inverting a composite condition twice, the parentheses were left. This also removes those unnecessary parentheses when applying the invert-if assist.
Co-authored-by: Jesse Bakker <github@jessebakker.com>
6921: Higher-ranked trait bounds for where clauses r=flodiebold a=Veykril
There is a slight problem with this which is also noted in a FIXME now but `LifetimeParameters` of these ForLifetime where clauses allocate the lifetimes in the corresponding arena as if they were lifetimes of the item itself and not just the clause they belong to. I wasn't entirely sure what I could do about this but given nothing really uses lifetimes like that currently I figured it might be fine? Open to suggestions for that problem.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6946: Better fuzzy heuristics r=matklad a=SomeoneToIgnore
Continuation of the https://github.com/rust-analyzer/rust-analyzer/pull/6922, mainly created for a test.
Turns out our current completions tests were sorting the completions by label, I had to remove that to test the order properly and update this order in a bunch of tests (ergo the changes)
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
6948: Add API for mapping `Attr` back to its syntax node r=jonas-schievink a=jonas-schievink
This will be useful for emitting diagnostics pertaining to a specific attribute
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Curiously, LSP uses different enums for those, and unsurprising and
annoyingly, there are things which exist in one but not in the other.
Let's not repeat the mistake and unify the two things
6901: Temp fixes panic caused by no ast for proc-macro r=maklad a=edwin0cheng
There are some panic when hover/goto definition for proc-macro. It is because in current design, we don't have `ast-node` for proc-macro and then it trigger [this](479d1f7eec/crates/hir/src/has_source.rs (L116)) line to panic.
This PR is a temp fix for all of these similar to bd4c352831/crates/completion/src/render/macro_.rs (L42)
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
6912: Default to host platform for cargo metadata r=jonhoo a=jonhoo
This modifies the logic for calling cargo metadata so that it will use
the host platform if no explicit target platform is given. This is
needed since cargo metadata defaults to outputting information for _all_
targets.
Fixes#6908.
Co-authored-by: Jon Gjengset <jongje@amazon.com>
Co-authored-by: Jon Gjengset <jon@thesquareplanet.com>
We used to have `Def` suffix for all symbols, but we moved off from
that. `FunctionDef` isn't better than `Function`. Looks like we've
forgot to change `Impl` though!
6907: Lifetime reference search r=matklad a=Veykril
PR #6787 but rewritten to make use of the HIR now. This only applies to Lifetimes, not labels. Also Higher-Ranked Trait Bounds aren't supported yet, but I feel like this PR is big enough as is which is why I left them out after noticing I forgot about them.
Supporting renaming required slight changes in the renaming module as lifetime names aren't allowed for anything but lifetimes(and labels) and vice versa for normal names.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
This modifies the logic for calling cargo metadata so that it will use
the host platform if no explicit target platform is given. This is
needed since cargo metadata defaults to outputting information for _all_
targets.
Fixes#6908.
ItemTree is per-file, so there is no unique crate associated with it.
This means that it cannot know the active CfgOptions and thus couldn't
handle `cfg_attr`.
Prepare it for `cfg_attr`s by avoiding accessing attributes.
6896: Node-ify lifetimes r=jonas-schievink a=Veykril
Let's see if this passes the tests 🤞
Depends on https://github.com/rust-analyzer/ungrammar/pull/15
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6897: Basic support for macros 2.0 r=jonas-schievink a=jonas-schievink
This adds support for (built-in-only) macros 2.0, and removes some hacks used for builtin derives, which are declared via macros 2.0 in libcore.
First steps for https://github.com/rust-analyzer/rust-analyzer/issues/2248.
Blocked on https://github.com/rust-analyzer/ungrammar/pull/16.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6861: generate default implementation for an enum from an enum variant #6860 r=matklad a=bnjjj
close#6860
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6889: Resolve `macro-error` diagnostics on asm & llvm_asm r=matklad a=lf-
We currently stub these out as returning unit.
This fixes spurious RA `macro-error` diagnostics introduced somewhere around 0.2.400 in the following:
```rust
unsafe { asm!(""); llvm_asm!(""); }
```
I'd ideally like to write a unit test for this, but I'm not familiar with where the tests for `hir_expand` are.
Thanks to @edwin0cheng for help on resolving this issue.
Co-authored-by: lf- <lf-@users.noreply.github.com>
6862: Add LifetimeParam resolving to Semantics r=matklad a=Veykril
This is stuff required for the lifetime references/definitions PR. I pulled this out to make it easier to review as well as because there is one thing that still has to be addressed which can be found in the review comments.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Since we just tried running `rustup component add`, it doesn't make sense to me
to recommend trying that again. If we're reaching this case, it's probably more
likely that rustc was installed via package manager, in which case the source
should be installed the same way (e.g. if you install the rust-src package on
Ubuntu it will install a symlink in the right place to make our sysroot
detection work).
6852: Ignore lifetime params in substitutions r=matklad a=Veykril
[`hir_ty::utils::Generics`](https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/hir_ty/src/utils.rs#L153) currently only assumes type parameters but not lifetime parameters and therefor creates incorrect index and length calculations, this PR just makes the use sites ignore LifetimeGenerics for now.
This fixes the panic at least locally for me for `analysis-stats`. Funnily enough this panic prevented me from using reference search for the `args` field to fix this problem.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6818: Add Lifetimes to the HIR r=matklad a=Veykril
This doesn't handle resolve yet as I don't know yet how that will be used. I'll get to that once I start moving the lifetime reference PR to the hir.
This also adds a new `hir` name type for lifetimes and labels, `hir::LifetimeName`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6839: Infer labeled blocks r=flodiebold a=Veykril
The test should cover all the interesting cases I believe(main part of it is copied from the loop label break test above it).
The test is indented to stay consistent with the rest of the tests in the file, I can dedent all the tests in the file in a follow up PR if desired.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6819: Add builtin attributes for use in nameres r=jonas-schievink a=jonas-schievink
These are not yet used, but have to go through nameres later in order to support procedural macro attributes
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
derive(Clone, Copy) reads better than derive(Copy, Clone).
However, we preserve the reverse ordering in the lookup text for
sorting purposes. That way, it's convenient to type just `Ord` to
derive everything.
6807: Replicate Cargo environment variables r=jonas-schievink a=jonas-schievink
These might be relied on by procedural macros, and can also be accessed via `env!`.
Required for fixing https://github.com/rust-analyzer/rust-analyzer/issues/6696. We do not yet propagate these to any proc macros though.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6804: Bump the macro token limit r=jonas-schievink a=jonas-schievink
Should fix https://github.com/rust-analyzer/rust-analyzer/issues/6504
Not entirely sure what the previous limit was based on, but it looks like it does get hit in practice.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6785: Fix "no value set for FileTextQuery(FileId(..))" r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/6622
Let's hope I got it right this time, but I feel like I slowly begin to understand the main loop logic.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
6771: Properly attach inner attributes in Attrs::new r=matklad a=Veykril
Properly attach inner and outer attributes to the things they actually belong to in the HIR. ~~I can add some tests for this if wanted once I know where to put them/how to test for this.~~ Put some tests into `hover.rs`.
So the following snippet
```rust
mod foo {
//! Hello
}
```
now shows `Hello` on hover 🎉Fixes#2148
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
