7984: Improve version display r=matklad a=lnicola
Maybe closes#7854
The version string for unreleased builds looks like this now:
```
$ rust-analyzer --version
rust-analyzer 2021-03-08-159-gc0459c535
```
Release builds should only have the tag name (`2021-03-15`).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
7994: Speed up mbe matching in heavy recursive cases r=edwin0cheng a=edwin0cheng
In some cases (e.g. #4186), mbe matching is very slow due to a lot of copy and allocation for bindings, this PR try to solve this problem by introduce a semi "link-list" approach for bindings building.
I used this [test case](https://github.com/weiznich/minimal_example_for_rust_81262) (for `features(32-column-tables)`) to run following command to benchmark:
```
time rust-analyzer analysis-stats --load-output-dirs ./
```
Before this PR : 2 mins
After this PR: 3 seconds.
However, for 64-column-tables cases, we still need 4 mins to complete.
I will try to investigate in the following weeks.
bors r+
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7904: Improved completion sorting r=JoshMcguigan a=JoshMcguigan
I was working on extending #3954 to apply completion scores in more places (I'll have another PR open for that soon) when I discovered that actually completion sorting was not working for me at all in `coc.nvim`. This led me down a bit of a rabbit hole of how coc and vs code each sort completion items.
Before this PR, rust-analyzer was setting the `sortText` field on completion items to `None` if we hadn't applied any completion score for that item, or to the label of the item with a leading whitespace character if we had applied any completion score. Completion score is defined in rust-analyzer as an enum with two variants, `TypeMatch` and `TypeAndNameMatch`.
In vs code the above strategy works, because if `sortText` isn't set [they default it to the label](b4ead4ed66). However, coc [does not do this](e211e36147/src/completion/complete.ts (L245)).
I was going to file a bug report against coc, but I read the [LSP spec for the `sortText` field](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_completion) and I feel like it is ambiguous and coc could claim what they do is a valid interpretation of the spec.
Further, the existing rust-analyzer behavior of prepending a leading whitespace character for completion items with any completion score does not handle sorting `TypeAndNameMatch` completions above `TypeMatch` completions. They were both being treated the same.
The first change this PR makes is to set the `sortText` field to either "1" for `TypeAndNameMatch` completions, "2" for `TypeMatch` completions, or "3" for completions which are neither of those. This change works around the potential ambiguity in the LSP spec and fixes completion sorting for users of coc. It also allows `TypeAndNameMatch` items to be sorted above just `TypeMatch` items (of course both of these will be sorted above completion items without a score).
The second change this PR makes is to use the actual completion scores for ref matches. The existing code ignored the actual score and always assumed these would be a high priority completion item.
#### Before
Here coc just sorts based on how close the items are in the file.
#### After
Here we correctly get `zzz` first, since that is both a type and name match. Then we get `ccc` which is just a type match.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
7961: add user docs for ssr assist r=JoshMcguigan a=JoshMcguigan
@matklad
This is a small follow up on #7874, adding user docs for the SSR assist functionality. Since most other assists aren't handled this way I wasn't sure exactly how we wanted to document this, so feel free to suggest alternatives.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
6822: Read version of rustc that compiled proc macro r=edwin0cheng a=jsomedon
Signed-off-by: Jay Somedon <jay.somedon@outlook.com>
This PR is to fix#6174.
I basically
* added two methods, `read_version` and `read_section`(used by `read_version`)
* two new crates `snap` and `object` to be used by those two methods
I just noticed that some part of code were auto-reformatted by rust-analyzer on file save. Does it matter?
Co-authored-by: Jay Somedon <jay.somedon@outlook.com>
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7878: Remove `item_scope` field from `Body` r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/7632
Instead of storing an `ItemScope` filled with inner items, we store the list of `BlockId`s for all block expressions that are part of a `Body`. Code can then query the `block_def_map` for those.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
7873: Consider unresolved qualifiers during flyimport r=matklad a=SomeoneToIgnore
Closes https://github.com/rust-analyzer/rust-analyzer/issues/7679
Takes unresolved qualifiers into account, providing better completions (or none, if the path is resolved or do not match).
Does not handle cases when both path qualifier and some trait has to be imported: there are many extra issues with those (such as overlapping imports, for instance) that will require large diffs to address.
Also does not do a fuzzy search on qualifier, that requires some adjustments in `import_map` for better queries and changes to the default replace range which also seems relatively big to include here.
7933: Improve compilation speed r=matklad a=matklad
bors r+
🤖
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
7898: generate_function assist: infer return type r=JoshMcguigan a=JoshMcguigan
This PR makes two changes to the generate function assist:
1. Attempt to infer an appropriate return type for the generated function
2. If a return type is inferred, and that return type is not unit, don't render the snippet
```rust
fn main() {
let x: u32 = foo$0();
// ^^^ trigger the assist to generate this function
}
// BEFORE
fn foo() ${0:-> ()} {
todo!()
}
// AFTER (only change 1)
fn foo() ${0:-> u32} {
todo!()
}
// AFTER (change 1 and 2, note the lack of snippet around the return type)
fn foo() -> u32 {
todo!()
}
```
These changes are made as two commits, in case we want to omit change 2. I personally feel like it is a nice change, but I could understand there being some opposition.
#### Pros of change 2
If we are able to infer a return type, and especially if that return type is not the unit type, the return type is almost as likely to be correct as the argument names/types. I think this becomes even more true as people learn how this feature works.
#### Cons of change 2
We could never be as confident about the return type as we are about the function argument types, so it is more likely a user will want to change that. Plus it is a confusing UX to sometimes have the cursor highlight the return type after triggering this assist and sometimes not have that happen.
#### Why omit unit type?
The assumption is that if we infer the return type as unit, it is likely just because of the current structure of the code rather than that actually being the desired return type. However, this is obviously just a heuristic and will sometimes be wrong. But being wrong here just means falling back to the exact behavior that existed before this PR.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
7891: Improve handling of rustc_private r=matklad a=DJMcNab
This PR changes how `rust-analyzer` handles `rustc_private`. In particular, packages now must opt-in to using `rustc_private` in `Cargo.toml`, by adding:
```toml
[package.metadata.rust-analyzer]
rustc_private=true
```
This means that depending on crates which also use `rustc_private` will be significantly improved, since their dependencies on the `rustc_private` crates will be resolved properly.
A similar approach could be used in #6714 to allow annotating that your package uses the `test` crate, although I have not yet handled that in this PR.
Additionally, we now only index the crates which are transitive dependencies of `rustc_driver` in the `rustcSource` directory. This should not cause any change in behaviour when using `rustcSource: "discover"`, as the source used then will only be a partial clone. However, if `rustcSource` pointing at a local checkout of rustc, this should significantly improve the memory usage and lower indexing time. This is because we avoids indexing all crates in `src/tools/`, which includes `rust-analyzer` itself.
Furthermore, we also prefer named dependencies over dependencies from `rustcSource`. This ensures that feature resolution for crates which are depended on by both `rustc` and your crate uses the correct set for analysing your crate.
See also [introductory zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Fixed.20crate.20graphs.20and.20optional.20builtin.20crates/near/229086673)
I have tested this in [priroda](https://github.com/oli-obk/priroda/), and it provides a significant improvement to the development experience (once I give `miri` the required data in `Cargo.toml`)
Todo:
- [ ] Documentation
This is ready to review, and I will add documentation if this would be accepted (or if I get time to do so anyway)
Co-authored-by: Daniel McNab <36049421+DJMcNab@users.noreply.github.com>
7892: Fix TokenStream::from_str for input consisting of a single group with delimiter r=edwin0cheng a=kevinmehall
TokenStream holds a `tt::Subtree` but assumes its `delimiter` is always `None`. In particular, the iterator implementation iterates over the inner `token_trees` and ignores the `delimiter`.
However, `TokenStream::from_str` violated this assumption when the input consists of a single group by producing a Subtree with an outer delimiter, which was ignored as seen by a procedural macro.
`tt::Subtree` is just `pub delimiter: Option<Delimiter>, pub token_trees: Vec<TokenTree>`, so a Subtree that is statically guaranteed not to have a delimiter is just `Vec<TokenTree>`.
Fixes#7810Fixes#7875
Co-authored-by: Kevin Mehall <km@kevinmehall.net>
7865: preserve escape sequences when replacing string with char r=Veykril a=jDomantas
Currently it replaces escape sequence with the actual value, which is very wrong for `"\n"`.
Co-authored-by: Domantas Jadenkus <djadenkus@gmail.com>
`TokenStream` assumes that its subtree's delimeter is `None`, and this
should be encoded in the type system instead of having a delimiter field
that is mostly ignored.
`tt::Subtree` is just `pub delimiter: Option<Delimiter>, pub
token_trees: Vec<TokenTree>`, so a Subtree that is statically guaranteed
not to have a delimiter is just Vec<TokenTree>.
TokenStream holds a `tt::Subtree` but assumes its `delimiter` is always
`None`. In particular, the iterator implementation iterates over the
inner `token_trees` and ignores the `delimiter`.
However, `TokenStream::from_str` violated this assumption when the input
consists of a single Group by producing a Subtree with an outer
delimiter, which was ignored as seen by a procedural macro.
In this case, wrap an extra level of Subtree around it.
Fixes#7810Fixes#7875
This is a hack to work around miri being included in
our analysis of rustc-dev
Really, we should probably use an include set of the actual root libraries
I'm not sure how those are determined however
7880: Honor snippet capability when using the extract function assist r=lnicola a=Arthamys
This fixes issue #7793
Co-authored-by: san <san@alien.parts>
7870: Use chalk_ir::AdtId r=Veykril a=Veykril
It's a bit unfortunate that we got two AdtId's now(technically 3 with the alias in the chalk module but that one won't allow pattern matching), one from hir_def and one from chalk_ir(hir_ty). But the hir_ty/chalk one doesn't leave hir so it shouldn't be that bad I suppose. Though if I see this right this will happen for almost all IDs.
I imagine most of the intermediate changes to using chalk ids will turn out not too nice until the refactor is over.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7795: Show docs on hover for keywords and primitives r=matklad a=Veykril
It's a bit annoying that this requires the `SyntaxNode` and `Semantics` to be pulled through `hover_for_definition` just so we can get the `std` crate but I couldn't think of a better way.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7335: added region folding r=matklad a=LucianoBestia
Regions of code that you'd like to be folded can be wrapped with `// #region` and `// #endregion` line comments.
This is called "Region Folding". It is originally available for many languages in VSCode. But Rust-analyzer has its own folding function and this is missing.
With this Pull Request I am suggesting a simple solution.
The regions are a special kind of comments, so I added a bit of code in the comment folding function.
The regex to match are: `^\s*//\s*#?region\b` and `^\s*//\s*#?endregion\b`.
The number of space characters is not important. There is an optional # character. The line can end with a name of the region.
Example:
```rust
// 1. some normal comment
// region: test
// 2. some normal comment
calling_function(x,y);
// endregion: test
```
I added a test for this new functionality in `folding_ranges.rs`.
Please, take a look and comment.
I found that these exact regexes are already present in the file `language-configuration.json`, but I don't find a way to read this configuration. So my regex is hardcoded in the code.
7691: Suggest name in extract variable r=matklad a=cpud36
Generate better default name in extract variable assist as was mentioned in issue #1587
# Currently supported
(in order of declining precedence)
1. Expr is argument to a function; use corresponding parameter name
2. Expr is result of a function or method call; use this function/method's name
3. Use expr type name (if possible)
4. Fallback to `var_name` otherwise
# Showcase
# Questions
* Should we more aggressively strip known types? E.g. we already strip `&T -> T`; should we strip `Option<T> -> T`, `Result<T, E> -> T`, and others?
* Integers and floats use `var_name` by default. Should we introduce a name, like `i`, `f` etc?
* Can we return a list and suggest a name when renaming(like IntelliJ does)?
* Should we add counters to remove duplicate variables? E.g. `type`, `type1`, type2`, etc.
Co-authored-by: Luciano Bestia <LucianoBestia@gmail.com>
Co-authored-by: Luciano <31509965+LucianoBestia@users.noreply.github.com>
Co-authored-by: Vladyslav Katasonov <cpud47@gmail.com>
7827: Fix proc macro TokenStream::from_str token ids r=vlad20012 a=vlad20012
To be honest, I don't know what it changes from a user perspective.
Internally, this fixes spans (token ids) of a `TokenStream` parsed from a string:
```rust
#[proc_macro_derive(FooDerive)]
pub fn foo_derive(item: TokenStream) -> TokenStream {
"fn foo() {}".parse().unwrap()
}
```
Previously, `TokenStream` was constructed from tokens with incremental ids (that conflicted with call-site tokens). Now they are `-1`.
Co-authored-by: vlad20012 <beskvlad@gmail.com>
7829: Bump deps r=matklad a=lnicola
Unfortunately, this brings a bunch of proc macros dep because `cargo-metadata` went full-in on `derive-builder`. I'm not sure what we can do here..
7833: Use chalk_ir::Mutability r=Veykril a=Veykril
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7778: Fix lowering trailing self paths in UseTrees r=Veykril a=Veykril
Noticed that hovering over `self` in a use tree like `use foo::bar::{self}` showing documentation and such for the current module instead of `bar`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7819: Speedup heavy tests r=matklad a=matklad
bors r+
🤖
7820: Update vscode README with a small features list r=matklad a=Veykril
Nothing grande but I figured this is a bit better than showing almost nothing
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7813: Inline TypeCtor into Ty r=flodiebold a=Veykril
This removes the `ApplicationTy` variant from `Ty` bringing the representation a lot closer to chalk's `TyKind`.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7804: Introduce TypeCtor::Scalar r=lnicola a=Veykril
`TypeCtor::Int(..) | TypeCtor::Float(..) | TypeCtor::Char | TypeCtor::Bool` => `TypeCtor::Scalar(..)`, in this case we can actually just straight up use `chalk_ir::Scalar` already since its just a POD without any IDs or anything.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7797: Format generated lints and features manually r=matklad a=lnicola
As `quote` and `rustfmt` leave them on a single line, which makes running `grep` in the repository quite annoying.
Also removes a dead `gen_features.rs` file (`gen_lint_completions.rs` does the same thing).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
7566: Add benchmark tests for mbe r=matklad a=edwin0cheng
This PR add more real world tests dumped from `rust-analyzer analysis-stats .` to benchmark its performance.
cc #7513
r? @matklad
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
7741: Add convert_for_to_iter_for_each assist r=mattyhall a=mattyhall
Implements one direction of #7681
I wonder if this tries to guess too much at the right thing here. A common pattern is:
```rust
let col = vec![1, 2, 3];
for v in &mut col {
*v *= 2;
}
// equivalent to:
col.iter_mut().for_each(|v| *v *= 2);
```
I've tried to detect this case by checking if the expression after the `in` is a (mutable) reference and if not inserting iter()/iter_mut(). This is just a convention used in the stdlib however, so could sometimes be wrong. I'd be happy to make an improvement for this, but not sure what would be best. A few options spring to mind:
1. Only allow this for types that are known to have iter/iter_mut (ie stdlib types)
2. Try to check if iter/iter_mut exists and they return the right iterator type
3. Don't try to do this and just add `.into_iter()` to whatever is after `in`
Co-authored-by: Matt Hall <matthew@quickbeam.me.uk>
7732: Don't lower TypeBound::Lifetime as GenericPredicate::Error r=flodiebold a=Veykril
Basically we just discard the typebound for now instead when lowering to `GenericPredicate`. I think this shouldn't have any other side effects?
Fixes #7683(hopefully for real this time)
I also played around with introducing `GenericPredicate::LifetimeOutlives` and `GenericPredicate::TypeOutlives`(see b9d6904845) but that won't fix this issue(at least not for now) due to lifetime predicate mismatches when resolving methods so I figure this is a good way to fix it for now.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7699: Implement ast::AstNode for NameLike and move it to node_ext r=matklad a=Veykril
With this `search`(and 2 other modules) don't necessarily go through 3 calls of `find_node_at_offset_with_descend` to find the correct node. Also makes the code that searches for NameLikes a bit easier on the eyes imo, though that can be fixed with just a helper function as well so its not that relevant.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7705: Show hover info of the definition of ConstReference patterns instead of its type r=Veykril a=Veykril
Closes#7671
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Reading through the code for diagnostics and observing debug logs, I noticed
that diagnostics are transmitted after every change for every opened file,
even if they haven't changed (especially visible for files with no diagnostics).
This change avoids marking files as "changed" if diagnostics are the same to what
was already sent before. This will only work if diagnostics are always produced in
the same order, but from my limited testing it seems this is the case.
7703: Allow comments between newlines in chaining hints r=Veykril a=unratito
Currently, chaining hints are not generated if there are comments between newlines, which is a very common pattern:
```rust
let vec = (0..10)
// Multiply by 2
.map(|x| x * 2)
// Add 3
.map(|x| x + 3)
.collect::<Vec<i32>>();
```
Besides, it seems a bit weird that this piece of code generates a chaining hint:
```rust
let vec = (0..10)
.collect::<Vec<i32>>();
```
But this one doesn't:
```rust
let vec = (0..10)
// This is a comment
.collect::<Vec<i32>>();
```
Co-authored-by: Paco Soberón <unratito@gmail.com>
7690: Extract `fn load_workspace(…)` from `fn load_cargo(…)` r=matklad a=regexident
Unfortunately in https://github.com/rust-analyzer/rust-analyzer/pull/7595 I forgot to `pub use` (rather than just `use`) the newly introduced `LoadCargoConfig`.
So this PR fixes this now.
It also:
- splits up `fn load_cargo` into a "workspace loading" and a "project loading" phase
- adds a `progress: &dyn Fn(String)` to allow third-parties to provide CLI progress updates, too
The motivation behind both of these is the fact that rust-analyzer currently does not support caching.
As such any third-party making use of `ra_ap_…` needs to providing a caching layer itself.
Unlike for rust-analyzer itself however a common use-pattern of third-parties is to analyze a specific target (`--lib`/`--bin <BIN>`/…) from a specific package (`--package`). The targets/packages of a crate can be obtained via `ProjectWorkspace::load(…)`, which currently is performed inside of `fn load_cargo`, effectively making the returned `ProjectWorkspace` inaccessible to the outer caller. With this information one can then provide early error handling via CLI (in case of ambiguities or invalid arguments, etc), instead of `fn load_cargo` failing with a possibly obscure error message. It also allows for annotating the persisted caches with its specific associated package/target selector and short-circuit quickly if a matching cache is found on disk, significantly cutting load times.
Before:
```rust
pub struct LoadCargoConfig {
pub cargo_config: &CargoConfig,
pub load_out_dirs_from_check: bool,
pub with_proc_macro: bool,
}
pub fn load_cargo(
root: &Path,
config: &LoadCargoConfig
) -> Result<(AnalysisHost, vfs::Vfs)> {
// ...
}
```
After:
```rust
pub fn load_workspace(
root: &Path,
config: &CargoConfig,
progress: &dyn Fn(String),
) -> Result<ProjectWorkspace> {
// ...
}
pub struct LoadCargoConfig {
pub load_out_dirs_from_check: bool,
pub with_proc_macro: bool,
}
pub fn load_cargo(
ws: ProjectWorkspace,
config: &LoadCargoConfig,
progress: &dyn Fn(String),
) -> Result<(AnalysisHost, vfs::Vfs)> {
// ...
}
```
Co-authored-by: Vincent Esche <regexident@gmail.com>
7657: utf8 r=matklad a=matklad
- Prepare for utf-8 offsets
- reduce code duplication in tests
- Make utf8 default, implement utf16 in terms of it
- Make it easy to add additional context for offset conversion
- Implement utf8 offsets
closes#7453
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
7687: Specialization for async traits r=matklad a=arnaudgolfouse
Fixes#7669.
Adapting the parser seemed to be all that was needed, but I am not very experienced with the codebase. Is this enough ?
Co-authored-by: Arnaud <arnaud.golfouse@laposte.net>
7620: Support control flow in `extract_function` assist r=matklad a=cpud36
Support `return`ing from outer function, `break`ing and `continue`ing outer loops when extracting function.
# Example
Transforms
```rust
fn foo() -> i32 {
let items = [1,2,3];
let mut sum = 0;
for &item in items {
<|>if item == 42 {
break;
}<|>
sum += item;
}
sum
}
```
Into
```rust
fn foo() -> i32 {
let items = [1,2,3];
let mut sum = 0;
for &item in items {
if fun_name(item) {
break;
}
sum += item;
}
sum
}
fn fun_name(item: i32) -> bool {
if item == 42 {
return true;
}
false
}
```
# Features
Supported variants
- break and function does not return => uses `bool` and plain if
- break and function does return => uses `Option<T>` and matches on it
- break with value and function does not return => uses `Option<T>` and if let
- break with value and function does return => uses `Result<T, U>` and matches on t
- same for `return` and `continue`(but we can't continue with value)
Assist does handle nested loops and nested items(like functions, modules, impls)
Try `expr?` operator is allowed together with `return Err(_)` and `return None`.
`return expr` is not allowed.
# Not supported
## Mixing `return` with `break` or `continue`
If we have e.g. a `return` and a `break` in the selected code, it is unclear what the produced code should look like.
We can try `Result<T, Option<U>>` or something like that, but it isn't idiomatic, nor it is established. Otherwise, implementation
is relatively simple.
## `break` with label
Not sure how to handle different labels for multiple `break`s.
[edit] implemented try `expr?`
Co-authored-by: Vladyslav Katasonov <cpud47@gmail.com>
7661: Start LSP 3.17 support r=kjeremy a=kjeremy
Companion to https://github.com/gluon-lang/lsp-types/pull/199 which <strike>has not been merged yet</strike> has been merged.
This doesn't opt into any 3.17 functionality yet.
Co-authored-by: Jeremy Kolb <kjeremy@gmail.com>
7656: Implement constructor usage search for almost all items r=matklad a=Veykril
This PR moves the filering for enum constructors to the HIR, with this unprefixed variants as well as when the enum has been renamed via use will then still show up properly.
We now walk the ast of the `NameRef` up until we find a `PathExpr`(which also handles `CallExpr` for tuple-type structs and variants already) or a `RecordExpr`. For enum search we then take the `path` out of that expression and do a resolution on it to compare it with the definition enum.
With this PR we now support searching for all constructor literals, Unit-, Tuple- and Record-Structs, Unit-, Tuple- and Record-Variants as well as Unions.
There is one shortcoming due to how the search is triggered. Unit Variants constructors can't be searched as we have no position for it to kick off the search(since a comma doesn't have to exist for the last variant).
Closes#2549 though it doesn't implement it as outlined in the issue since the reference kind was removed recently, though I believe the approach taken here is better personally.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7643: Automatically detect the rustc-src directory (fixes#3517) r=matklad a=bnjbvr
If the configured rustcSource was not set, then try to automatically
detect a source for the sysroot rustc directory.
I wasn't sure how to do it in the case of the project.json file, though.
7663: Tolerate spaces in nix binary patching r=matklad a=CertainLach
If path to original file contains space (I.e on code insiders, where
default data directory is ~/Code - Insiders/), then there is syntax
error evaluating src arg.
Instead pass path as str, and coerce to path back in nix expression
Co-authored-by: Benjamin Bouvier <public@benj.me>
Co-authored-by: Yaroslav Bolyukin <iam@lach.pw>
7668: Finalize rename infra rewrite r=matklad a=Veykril
This should be the final PR in regards to rewriting rename stuff, #4290.
It addresses 3 things:
- Currently renaming import aliases causes some undesired behavior(see #5198) which is why this PR causes us to just return an error if an attempt at renaming an alias is made for the time being. Though this only prevents it from happening when the alias import is renamed, so its not too helpful.
- Fixes#6898
- If we are inside a macro file simply rename the input name node as there isn't really a way to do any of the fancy shorthand renames and similar things as for that we would have to exactly know what the macro generates and what not.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7664: refactor impl generation in assists r=Veykril a=jDomantas
Follow-up to #7659: all impl generation in assists (at least what I found) is now done through `utils::{generate_impl_text, generate_trait_impl_text}`.
Co-authored-by: Domantas Jadenkus <djadenkus@gmail.com>
7665: Don't classify attribute macros as their path unless it's a function with the proc_macro_attribute attribute r=Veykril a=Veykril
bors r+
Closes#6389
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
For all struct kinds, unions and enums, as well as for record- and
tuple-variants but not for unit-variants, as these have no trailing
character we can anchor the search to. Functionality wise it is
implemented though.
In some situations we reloaded the workspace in the tests after having reported
to be ready. There's two fixes here:
1. Add a version to the VFS config and include that version in progress reports,
so that we don't think we're done prematurely;
2. Delay status transitions until after changes are applied. Otherwise the last
change during loading can potentially trigger a workspace reload, if it contains
interesting changes.
7617: Add getter/setter assists r=Veykril a=yoshuawuyts
This patch makes progress towards the design outlined in https://github.com/rust-analyzer/rust-analyzer/issues/5943, and includes a small refactor which closes https://github.com/rust-analyzer/rust-analyzer/issues/7607. All together this patch does 4 things:
- Adds a `generate_getter` assist.
- Adds a `generate_getter_mut` assist.
- Adds a `generate_setter` assist.
- Moves the `generate_impl_text` function from `generate_new` into `utils` (which closes#7607).
## Design Notes
I've chosen to follow the [Rust API guidelines on getters](https://rust-lang.github.io/api-guidelines/naming.html#getter-names-follow-rust-convention-c-getter) as closely as possible. This deliberately leaves "builder pattern"-style setters out of scope.
Also, similar to https://github.com/rust-analyzer/rust-analyzer/pull/7570 this assist generates doc comments. I think this should work well in most cases, and for the few where it doesn't it's probably easily edited. This makes it slightly less correct than the #7570 implementation, but I think this is still useful enough to include for many of the same reasons.
The reason why this PR contains 3 assists, rather than 1, is because each of them is so similar to the others that it felt more noisy to do them separately than all at once. The amount of code added does not necessarily reflect that, but hope that still makes sense.
## Examples
**Input**
```rust
struct Person {
name: String, // <- cursor on "name"
}
```
**generate getter**
```rust
struct Person {
name: String,
}
impl Person {
/// Get a reference to the person's name.
fn name(&self) -> &String {
&self.name
}
}
```
**generate mut getter**
```rust
struct Person {
name: String,
}
impl Person {
/// Get a mutable reference to the person's name.
fn name_mut(&mut self) -> &mut String {
&mut self.name
}
}
```
**generate setter**
```rust
struct Person {
name: String,
}
impl Person {
/// Set the person's name.
fn set_name(&mut self, name: String) {
self.name = name;
}
}
```
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
7572: Add `find_or_create_impl_block` to assist utils r=matklad a=yoshuawuyts
This is another continuation of https://github.com/rust-analyzer/rust-analyzer/pull/7562, introducing a small util to either find an `impl` block, or create a new one if none exists. I copied this code from the `generate_new` assist into https://github.com/rust-analyzer/rust-analyzer/pull/7562, and this unifies both into a helper.
It doesn't feel super polished in its current state, but my hope is that this is enough of a starting point that it can be expanded on later. For example something that would be useful would be a flag which either returns the index of the start of the block, or the end of the block.
Anyway, I hope this is useful. Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
7574: Remove various redundant clones r=kjeremy a=yoshuawuyts
I noticed when running clippy through RA that there are a few instances where `clone` is called where it's not actually needed. I figured a small patch to remove these might be welcome here.
Thanks!
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
7505: Widen Highlights root range to covering element r=Veykril a=Veykril
There have been a few issues about/containing spurious syntax highlighting panics, which all seem to come from the `rust_analyzer::handlers::handle_semantic_tokens_range` request, which I believe this to be the cause of as the text range we want to highlight here is currently potentially smaller than that of the covering element, so we might highlight something that is inside the covering element, but outside of the text range we wish to highlight causing the assert to fail.
Unfortunately this isn't really easy to test since I have yet to find a reproducible cause(#7504 doesn't work for me cause I can't seem to checkout the given commit).
See #7504, #7298, #7299 and #7416, all of those contain an assertion failure in syntax highlighting, but only in the range request.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7570: Add doc gen to the `generate_enum_match_method` assist r=yoshuawuyts a=yoshuawuyts
Implements a small extension to https://github.com/rust-analyzer/rust-analyzer/pull/7562, generating default comments. I wasn't sure if this would fit the goals of Rust-Analyzer, so I chose to split it into a separate PR. This is especially useful when writing code in a codebase which uses `#![warn(missing_docs)]` lint, as many production-grade libraries do.
The comments we're generating here are similar to the ones found on [`Option::is_some`](https://doc.rust-lang.org/std/option/enum.Option.html#method.is_some) and [`Result::is_err`](https://doc.rust-lang.org/std/result/enum.Result.html#method.is_err). I briefly considered only generating these for `pub` types, but they seem small and unobtrusive enough that they're probably useful in the general case. Thanks!
## Example
__input__
```rust
pub(crate) enum Variant {
Undefined,
Minor, // cursor here
Major,
}
```
__output__
```rust
pub(crate) enum Variant {
Undefined,
Minor,
Major,
}
impl Variant {
/// Returns `true` if the variant is [`Minor`].
pub(crate) fn is_minor(&self) -> bool {
matches!(self, Self::Minor)
}
}
```
## Future Directions
This opens up the path to adding an assist for generating these comments on existing `is_` methods. This would make it both easy to document new code, and update existing code with documentation.
7571: Cleanup decl_check r=Veykril a=Veykril
bors r+
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
7562: add `generate_enum_match` assist r=matklad a=yoshuawuyts
This adds a `generate_enum_match` assist, which generates `is_` variants for enums (e.g. `Option::{is_none,is_some}` in std). This is my first attempt at contributing to Rust-Analyzer, so I'm not sure if I've gotten everything right. Thanks!
## Example
**Input**
```rust
pub(crate) enum Variant {
Undefined,
Minor, // cursor here
Major,
}
```
**Output**
```rust
pub(crate) enum Variant {
Undefined,
Minor,
Major,
}
impl Variant {
pub(crate) fn is_minor(&self) -> bool {
matches!(self, Self::Minor)
}
}
```
## Future Directions
I made this as a stepping stone for some of the more involved refactors (e.g. #5944). I'm not sure yet how to create, use, and test `window.showQuickPick`-based asssists in RA. But once that's possible, it'd probably be nice to be able to generate match methods in bulk through the quickpick UI rather than one-by-one:
```
[x] Select enum members to generate methods for. (3 selected) [ OK ]
---------------------------------------------------------------------------
[x] Undefined
[x] Minor
[x] Major
```
Co-authored-by: Yoshua Wuyts <yoshuawuyts+github@gmail.com>
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
7568: Fix merging of `segment_index` in path resolution r=jonas-schievink a=jonas-schievink
This caused associated item lookup to fail when modifying `resolver.rs` to handle block expressions with inner items.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7535: Extract function assist r=cpud36 a=cpud36
This PR adds `extract function/method` assist. closes#5409.
# Supported features
Assist should support extracting from expressions(`1`, `2 + 2`, `loop { }`) and from a series of statements, e.g.:
```rust
foo();
$0bar();
baz();$0
quix();
```
Assist also supports extracting parameters, like:
```rust
fn foo() -> i32 {
let n = 1;
$0n + 1$0
}
// -
fn foo() -> i32 {
let n = 1;
fun_name(n)
}
fn fun_name(n: i32) -> i32 {
n + 1
}
```
Extracting methods also generally works.
Assist allows referencing outer variables, both mutably and immutably, and handles handles access to variables local to extracted function:
```rust
fn foo() {
let mut n = 1;
let mut m = 2;
let mut moved_v = Vec::new();
let mut ref_mut_v = Vec::new();
$0
n += 1;
let k = 1;
moved_v.push(n);
let r = &mut m;
ref_mut_v.push(*r);
let h = 3;
$0
n = ref_mut_v.len() + k;
n -= h + m;
}
// -
fn foo() {
let mut n = 1;
let mut m = 2;
let mut moved_v = Vec::new();
let mut ref_mut_v = Vec::new();
let (k, h) = fun_name(&mut n, moved_v, &mut m, &mut ref_mut_v);
n = ref_mut_v.len() + k;
n -= h + m;
}
fn fun_name(n: &mut i32, mut moved_v: Vec<i32>, m: &mut i32, ref_mut_v: &mut Vec<i32>) -> (i32, i32) {
*n += 1;
let k = 1;
moved_v.push(*n);
let r = m;
ref_mut_v.push(*r);
let h = 3;
(k, h)
}
```
So we handle both input and output paramters
# Showcase
# Working with non-`Copy` types
Consider the following example:
```rust
fn foo() {
let v = Vec::new();
$0
let n = v.len();
$0
let is_empty = v.is_empty();
}
```
`v` must be a parameter to extracted function.
The question is, what type should it have.
It could be `v: Vec<i32>`, or `v: &Vec<i32>`.
The former is incorrect for `Vec<i32>`, but the later is silly for `i32`.
To resolve this we need to know if the type implements `Copy` trait.
I didn't find any api available from assists to query this.
`hir_ty::method_resolution::implements` seems relevant, but is isn't publicly re-exported from `hir`.
# Star(`*`) token and pointer dereference
If I understand correctly, in order to create expression like `*p`, one should use `ast::make::expr_prefix(T![*], ...)`, which
in turn calls `token(T![*])`.
`token` does not have star in `tokens::SOURCE_FILE`, so this panics.
I had to add `*` to `SOURCE_FILE` to make it work.
Correct me if this is not intended way to do this.
# Lowering access `value -> mut ref -> shared ref`
Consider the following example:
```rust
fn foo() {
let v = Vec::new();
$0 let n = v.len(); $0
}
```
`v` is not used after extracted function body, so both `v: &Vec<i32>` and `v: Vec<i32>` would work.
Currently the later would be chosen.
We can however check the body of extracted function and conclude that `v: &Vec<i32>` is sufficient.
Using `v: &Vec<i32>`(that is a minimal required access level) might be a better default.
I am unsure.
# Cleanup
The assist seems to be reasonably handling most of common cases.
If there are no concerns with code it produces(i.e. with test cases), I will start cleaning up
[edit]
added showcase
Co-authored-by: Vladyslav Katasonov <cpud47@gmail.com>
7541: Use block_def_map in body lowering (third time's the charm) r=jonas-schievink a=jonas-schievink
After https://github.com/rust-analyzer/rust-analyzer/pull/7380 and https://github.com/rust-analyzer/rust-analyzer/pull/7506 both had to be reverted, this should have finally resolved all remaining bugs.
Most importantly, the optimization to skip `block_def_map` computation when the block contains no inner items was fixed (which fortunately was simpler than expected).
I've ran `analysis-stats` on libstd locally, which works fine, and also ran this PR locally for a short while without issues.
Note that this *still* has no (or almost no) user-facing impact, because the rest of r-a still relies on some local item support hacks.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
there are a few currently limitations:
* no modifications of function body
* does not handle mutability and references
* no method support
* may produce incorrect results
I've noticed that there are various suggestions that rust-analyzer seems
to filter out, even if they make sense.
Here's an example of where it seems like there should be a suggestion,
but there isn't:
It turns out that this specific suggestion is not considered
`MachineApplicable`, which are the only suggestions that rust-analyzer
accepts. However if you read the documentation for `MachineApplicable`,
b3897e3d13/compiler/rustc_lint_defs/src/lib.rs (L27-L29)
then you realize that these are specifically only those suggestions that
rust-analyzer could even automatically apply (in some distant future,
behind some setting or so). Other suggestions that may have some
semantic impact do not use `MachineApplicable`. So all other suggestions
are still intended to be suggested to the user, just not automatically
applied without the user being consulted.
b3897e3d13/compiler/rustc_lint_defs/src/lib.rs (L22-L24)
So with that in mind, rust-analyzer should almost definitely not filter
out `MaybeIncorrect` (which honestly is named horribly, it just means
that it's a semantic change, not just a syntactical one).
Then there's `HasPlaceholders` which basically is just another semantic
one, but with placeholders. The user will have to make some adjustments,
but the suggestion still is perfectly valid. rust-analyzer could
probably detect those placeholders and put proper "tab through" markers
there for the IDE, but that's not necessary for now.
Then the last one is `Unspecified` which is so unknown that I don't even
know how to judge it, meaning that the suggestion should probably also
just be suggested to the user and then they can decide.
So with all that in mind, I'm proposing to get rid of the check for
Applicability entirely.
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>
