11437: [ide_completion] render if a function is async/const/unsafe in completion details r=Veykril a=jhgg
this change renders in the autocomplete detail, whether a function is async/const/unsafe.
i found myself wanting to know this information at a glance, so now it renders here:
Co-authored-by: Jake Heinz <jh@discordapp.com>
When using `F1`->`Rust Analyzer: Run` action on an `example`, pass its
`required-features` to `cargo run`. This allows to run examples that
were otherwise impossible to run with RA.
In code like this:
```rust
impl<T> Option<T> {
fn as_deref(&self) -> T::Target where T: Deref {}
}
```
when trying to resolve the associated type `T::Target`, we were only
looking at the bounds on the impl (where the type parameter is defined),
but the method can add additional bounds that can also be used to refer
to associated types. Hence, when resolving such an associated type, it's
not enough to just know the type parameter T, we also need to know
exactly where we are currently.
This fixes#11364 (beta apparently switched some bounds around).
11322: Extract function also extracts comments r=Vannevelj a=Vannevelj
Fixes#9011
The difficulty I came across is that the original assist works from the concept of a `ast::StmtList`, a node, but that does not allow me to (easily) represent comments, which are tokens. To combat this, I do a whole bunch of roundtrips: from the `ast::StmtList` I retrieve the `NodeOrToken`s it encompasses.
I then cast all `Node` ones back to a `Stmt` so I can apply indentation to it, after which it is again parsed as a `NodeOrToken`.
Lastly, I add a new `make::` api that accepts `NodeOrToken` rather than `StmtList` so we can write the comment tokens.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
11182: fix: don't panic on seeing an unexpected offset r=Veykril a=dimbleby
Intended as a fix, or at least a sticking plaster, for #11081.
I have arranged that [offset()](1ba9a924d7/crates/ide_db/src/line_index.rs (L105-L107)) returns `Option<TextSize>` instead of going out of bounds; other changes are the result of following the compiler after doing this.
Perhaps there's still an issue here - I suppose the server and client have gotten out of sync and that probably shouldn't happen in the first place? I see that https://github.com/rust-analyzer/rust-analyzer/issues/10138#issuecomment-913727554 suggests what sounds like a more substantial fix which I think might be aimed in this direction. So perhaps that one should be left open to cover such things?
Meanwhile, I hope that not-crashing is a good improvement: and I can confirm that it works out just fine in the repro I have at #11081.
Co-authored-by: David Hotham <david.hotham@metaswitch.com>
This patch makes RA understand `#![recursion_limit = "N"]` annotations.
- `crate_limits` query is moved to `DefDatabase`
- `DefMap` now has `recursion_limit: Option<u32>` field
This allows fetching crate limits like `recursion_limit`. The
implementation is currently dummy and just returns the defaults.
Future work: Use this query instead of the hardcoded constant.
Future work: Actually implement this query by parsing
`#![recursion_limit = N]` attribute.
11281: ide: parallel prime caches r=jonas-schievink a=jhgg
cache priming goes brrrr... the successor to #10149
---
this PR implements a parallel cache priming strategy that uses a topological work queue to feed a pool of worker threads the crates to index in parallel.
## todo
- [x] should we keep the old prime caches?
- [x] we should use num_cpus to detect how many cpus to use to prime caches. should we also expose a config for # of worker CPU threads to use?
- [x] something is wonky with cancellation, need to figure it out before this can merge.
Co-authored-by: Jake Heinz <jh@discordapp.com>
Fixes#8607.
This commit changes the auto-import functionality and causes it to add
imports after any leading comments, which are commonly license headers.
This does not affect comments on items as they're considered part of the
item itself and not separate.
11236: internal: Remove `InFile` wrapping from `DynMap` keys r=Veykril a=Veykril
We already store a `DynMap` per `(Container, HirFileId)` pair, so the `InFile` keys are already guruanteed to always be of the same file id
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11107: Fix generic type substitution in impl trait with assoc type r=pnevyk a=pnevyk
Fixes#11045
The path transform now detects if a type parameter that is being substituted has an associated type. In that case it is necessary (or safe in general case) to fully qualify the substitution with a trait which the associated type belongs to.
This PR also fixes the previous wrong behavior of the substitution that could create an invalid tree `PATH_TYPE -> PATH_TYPE -> ...`.
Co-authored-by: Petr Nevyhoštěný <petr.nevyhosteny@gmail.com>
11145: feat: add config to use reasonable default expression instead of todo! when filling missing fields r=Veykril a=bnjjj
Use `Default::default()` in struct fields when we ask to fill it instead of putting `todo!()` for every fields
before:
```rust
pub enum Other {
One,
Two,
}
pub struct Test {
text: String,
num: usize,
other: Other,
}
fn t_test() {
let test = Test {<|>};
}
```
after:
```rust
pub enum Other {
One,
Two,
}
pub struct Test {
text: String,
num: usize,
other: Other,
}
fn t_test() {
let test = Test {
text: String::new(),
num: 0,
other: todo!(),
};
}
```
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
Co-authored-by: Coenen Benjamin <benjamin.coenen@hotmail.com>
11220: Turbo fish assist: don't include lifetime parameters r=Veykril a=Vannevelj
Fixes#11219
The issue talks about three different types of params: type, const & lifetime. I wasn't entirely sure which ones are intended to be included here so I've gone for the type & const params (i.e. exclude lifetime).
I've added a test case for both a lifetime param and a const param. I'm still making my way through the rust book (chapter 7, yay) so I'm not too sure yet what these are but my testing shows that this approach generates code that compiles.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
11225: internal: Cleanup doc and attribute handling r=Veykril a=Veykril
(very vague PR title but as I tried to fix the mentioned issue I ran into more and more subtle things that were interwoven)
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11215
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11194: fix(gen-doc-assist): remove lifetimes in description of `new` r=Veykril a=numero-744
From wrong behavior:
```rust
/// Creates a new [`MyGenericStruct<'a, T>`].
```
to correct behavior:
```rust
/// Creates a new [`MyGenericStruct<T>`].
```
But I feel like there is a better way to implement it. Do you know if there is an existing function that could do the work of `lifetimes_removed()` below?
Co-authored-by: Côme ALLART <come.allart@etu.emse.fr>
11218: fix: Correct has_ref detection, avoiding duplicate &mut insertion on parameter completion r=Veykril a=weirane
The original code fails to detect there's a ref in scenarios such as `&mut s` and `& s` because `WHITESPACE` and `IDENT` got reversed.
Closes#11199.
Co-authored-by: Wang Ruochen <wrc@ruo-chen.wang>
11193: feat: Add config to replace specific proc-macros with dummy expanders r=Veykril a=Veykril
With this one can specify proc-macros from crates to expand into their input as a (temporary) workaround for the current completion problems with some of the bigger attribute proc-macros like `async_trait`.
This could've been done by just not expanding these macros, but that would require fiddling with nameres. I felt like this approach was simpler to pull off while also keeping the behaviour of the attributes/proc-macro in that they still expand instead of being dead syntax to us.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/11052
Usage(`async_trait` as example):
```jsonc
"rust-analyzer.procMacro.dummies": {
"async-trait": [ // crate name(as per its cargo.toml definition, not the dependency name)
"async_trait" // exported proc-macro name
]
},
```
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11204: fix: `replace_qualified_name_with_use` does not use full item path for replacements r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11195: Correctly pass through reference modifiers when extracting a variable r=Veykril a=Vannevelj
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10034
This will parse the field expression and look at whether it is marked `&` or `&mut` and include a modifier if appropriate. The original issue only mentions `&mut params` but I've found that this issue also occurs for `&mut locals` as well as `¶ms` and `&locals` so I've also added tests for them.
I'd definitely be interested in hearing where I can make my code more idiomatic for Rust.
11202: fix: Fix `apply_demorgan` assist hanging for certain binary expressions r=Veykril a=Veykril
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10963
bors r+
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11201: fix: Fix completions not considering ancestor items for attribute search r=Veykril a=Veykril
Turns out we never filled the `CompletionContext` with the attribute expansion of attributed impls and traits when typing in the assoc items, as we were only considering the assoc item to have an attribute to expand.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11190: fix(completions): improve fn_param r=dbofmmbt a=dbofmmbt
- insert commas around when necessary
- only suggest `self` completions when param list is empty
- stop suggesting completions for identifiers which are already on the param list
Closes#11085
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
- insert commas around when necessary
- only suggest `self` completions when param list is empty
- stop suggesting completions for identifiers which are already on the param list
11184: Correctly pass through mutable parameter references when extracting a function r=Veykril a=Vannevelj
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10277
I have based this investigation based on my understanding of [the Borrowing chapter](https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html) but I wasn't able to debug the test runs or see it in action in an IDE. I'll try to figure out how to do that for future PRs but for now, the tests seem to confirm my understanding. I'll lay out my hypothesis below.
Here we define the parameters for the to-be-generated function:
7409880a07/crates/ide_assists/src/handlers/extract_function.rs (L882)
Three values in particular are important here: `requires_mut`, `is_copy` and `move_local`. These will in turn be used here to determine the kind of parameter:
7409880a07/crates/ide_assists/src/handlers/extract_function.rs (L374-L381)
and then here to determine what transformation is needed for the calling argument:
7409880a07/crates/ide_assists/src/handlers/extract_function.rs (L383-L390)
which then gets transformed here:
7409880a07/crates/syntax/src/ast/make.rs (L381-L383)
What I believe is happening is that
* `requires_mut` is `false` (it already is marked as mutable),
* `is_copy` is `false` (`Foo` does not implement `Copy`), and
* `move_local` is `false` (it has further usages)
According to the pattern matching in `fn kind()`, that would lead to `ParamKind::SharedRef` which in turn applies a transformation that prepends `&`.
However if I look at the chapter on borrowing then we only need to mark an argument as a reference if we actually own it. In this case the value is passed through as a reference parameter into the current function which means we never had ownership in the first place. By including the additional check for a reference parameter, `move_local` now becomes `true` and the resulting parameter is now `ParamKind::Value` which will avoid applying any transformations. This was further obscured by the fact that you need further usages of the variable or `move_local` would be considered `true` after all.
I didn't follow it in depth but it appears this idea applies for both the generated argument and the generated parameter.
There are existing tests that account for `&mut` values but they refer to local variables for which we do have ownership and as such they didn't expose this issue.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
11061: Support "move if to guard" for if else chains r=weirane a=weirane
The idea is to first parse the if else chain into a vector of `(Condition, BlockExpr)`s until we reach an iflet branch, an else branch, or the end (the tail). Then add the match arms with guard for the vector, and add the tail with no if guard.
Because the whole original match arm is replaced and the generated code doesn't have redundent commas, I removed redundent commas in some test cases.
Closes#11033.
Co-authored-by: Wang Ruochen <wrc@ruo-chen.wang>
11088: closes#10446 hide type inlay hints r=Veykril a=Heinenen
Passes tests as described in #10446
Works for all happy cases, there may be some cases that I forgot as I am not that familiar with Rust and r-a (yet).
Co-authored-by: Heinenen <th.m.heinen@gmail.com>
11173: Allow adding partially resolved types r=Veykril a=SomeoneToIgnore
Sometimes when writing something like `let foo = Arc::new(Mutex::new(CrazyGenerics::new(HashMap::new())))`, I want/have to specify an explicit type for the expression.
Using turbofish isn't very readable and not always appreciated by guidelines, so `let foo: T` has to be filled.
To ease that, the PR enables the `add_explicit_type` assist on types that contain unknown types and some generics.
Fully unresolved types, arrays with unknown types and other known cases behave the same.
`_` placeholder was chosen to replace an unknown type:
```rust
let foo = HashMap::new();
// after assist usage, turns into
let foo: HashMap<_, _> = HashMap::new();
```
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
11169: internal: Handle macro calls better in highlighting r=Veykril a=Veykril
Introduces a new semantic highlighting tag for the `!` character of macro calls.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/10962
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
11136: Turbo fish assist supports multiple type arguments r=matklad a=Vannevelj
This fixes#11135 (changelog: bug).
I've only started using Rust a few days ago but saw this issue on the top of the list when I looked at this repo. I based myself on [this blog post](https://techblog.tonsser.com/posts/what-is-rusts-turbofish) to understand what a "turbo fish" is so let me know if I missed anything.
Co-authored-by: Jeroen Vannevel <jer_vannevel@outlook.com>
11151: feat: correctly fallback to notify if the clinet-side file watching is not supported r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
The direct reason for this is to fix CI on windows, which seems to fail
for some reason after we fixed the watcher-selection logic which (I
think) changed the tests behavior to use notify rather than client.
But this patch seems to make sense in general -- file watching is
notoriously finicky, so controlling it explicitly leads to less fragile
tests.
This has to re-introduce the `sink` pattern, because doing this purely
with iterators is awkward :( Maaaybe the event vector was a false start?
But, anyway, I like the current factoring more -- it sort-of obvious
that we do want to keep ws-attachment business in the parser, and that
we also don't want that to depend on the particular tree structure. I
think `shortcuts` module achieves that.
The general theme of this is to make parser a better independent
library.
The specific thing we do here is replacing callback based TreeSink with
a data structure. That is, rather than calling user-provided tree
construction methods, the parser now spits out a very bare-bones tree,
effectively a log of a DFS traversal.
This makes the parser usable without any *specifc* tree sink, and allows
us to, eg, move tests into this crate.
Now, it's also true that this is a distinction without a difference, as
the old and the new interface are equivalent in expressiveness. Still,
this new thing seems somewhat simpler. But yeah, I admit I don't have a
suuper strong motivation here, just a hunch that this is better.
11065: internal: Don't kick off inference in `Semantics::descend_into_macros_impl` r=Veykril a=Veykril
We do not need inference info here so there is no point in calculating it
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
10484: internal: Update match checking algorithm r=lnicola a=iDawer
Sync match checking algorithm with rust-lang/rust f31622a50 2021-11-12 (https://github.com/rust-lang/rust/pull/90813)
This update brings huge simplification to the match checking and introduces an easy to use machinery for pattern destructuring and also:
1. Add a function to do post-inference normalization `hir_ty::infer::normalize(...)`.
2. Store binding modes in `InferenceResult`.
Todo:
- [x] Rebase & test (https://github.com/rust-analyzer/rust-analyzer/pull/10484#issuecomment-996669665)
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
Co-authored-by: iDawer <ilnur.iskhakov.oss@outlook.com>
11062: fix: Don't say "a reference to" for `Copy` types in the generate getter assist r=Veykril a=patrick-gu
This changes the generate getter assist to not say "a reference to" in the documentation stub if the type is `Copy`, as the getter does not return a reference.
To determine whether the type is `Copy`, I have added an `is_copy` method to `ReferenceConversion`.
Co-authored-by: patrick-gu <55641350+patrick-gu@users.noreply.github.com>
This changes the generate getter assist to not say "a reference to" in the documentation stub if the type is Copy, as the getter does not return a reference.
