When extracting a field expression, if RA was unable to resolve the type of the
field, we would previously fall back to using "var_name" as the variable name.
Now, when the `Expr` being extracted matches a `FieldExpr`, we can use the
`NameRef`'s ident token as a fallback option.
fixes#10035
This change fixes#12705.
In `FunctionBody::analyze`, we need to search any `ClosureExpr`s we encounter
for any `NameRef`s, to ensure they aren't missed.
fix: Extract function from trait impl
This change fixes#10036, "Extract to function assist implements nonexistent
trait methods".
When we detect that the extraction is coming from within a trait impl, and that
a `self` param will be necessary, we adjust which `SyntaxNode` to `insert_after`,
and create a new empty `impl` block for the newly extracted function.
This change fixes#10036, "Extract to function assist implements nonexistent
trait methods".
When we detect that the extraction is coming from within a trait impl, and that
a `self` param will be necessary, we adjust which `SyntaxNode` to `insert_after`,
and create a new empty `impl` block for the newly extracted function.
This change fixes issue #10037, in more or less the most naive fashion
possible.
We continue to start with the hardcoded default of "fun_name", and now append a
counter to the end of it if that name is already in scope.
In the future, we can probably apply more heuristics here to wind up with more
useful names by default, but for now this resolves the immediate problem.
fix: Simplify macro statement expansion handling
I only meant to fix https://github.com/rust-lang/rust-analyzer/issues/12644 but that somehow turned into a rewrite of the statement handling ... at least this fixes a few more issues in the IDE layer now
fix: improve whitespace insertion in pretty printer
Fixes#12591
The `=>` token in the macro_rules! should be parsed as one fat arrow, but it ["requires a lot of changes in r-a"](143cc528b1), so I left it for the larger refactoring in the future and put a FIXME note.
feat: Show witnesses of non-exhaustiveness in `missing-match-arm` diagnostic
Shamelessly copied from rustc. Thus reporting format is same.
This extends public api `hir::diagnostics::MissingMatchArms` with `uncovered_patterns: String` field. It does not expose data for implementing a quick fix yet.
-----
Worth to note: current implementation does not give a comprehensive list of missing patterns. Also mentioned in [paper](http://moscova.inria.fr/~maranget/papers/warn/warn.pdf):
> One may think that algorithm I should make an additional effort to provide more
> non-matching values, by systematically computing recursive calls on specialized
> matrices when possible, and by returning a list of all pattern vectors returned by
> recursive calls. We can first observe that it is not possible in general to supply the
> users with all non-matching values, since the signature of integers is (potentially)
> infinite.
fix: trailing ':' on empty inactive reasons
## Description
Fixes trailing ':' even when there is no explanation. e.g.
``` sh
code is inactive due to #[cfg] directives:
```
## Issue
Fixes: #12615
feat: implement destructuring assignment
This is an attempt to implement destructuring assignments, or more specifically, type inference for [assignee expressions](https://doc.rust-lang.org/reference/expressions.html#place-expressions-and-value-expressions).
I'm not sure if this is the right approach, so I don't even expect this to be merged (hence the branch name 😉) but rather want to propose one direction we could choose. I don't mind getting merged if this is good enough though!
Some notes on the implementation choices:
- Assignee expressions are **not** desugared on HIR level unlike rustc, but are inferred directly along with other expressions. This matches the processing of other syntaxes that are desugared in rustc but not in r-a. I find this reasonable because r-a only needs to infer types and it's easier to relate AST nodes and HIR nodes, so I followed it.
- Assignee expressions obviously resemble patterns, so type inference for each kind of pattern and its corresponding assignee expressions share a significant amount of logic. I tried to reuse the type inference functions for patterns by introducing `PatLike` trait which generalizes assignee expressions and patterns.
- This is not the most elegant solution I suspect (and I really don't like the name of the trait!), but it's cleaner and the change is smaller than other ways I experimented, like making the functions generic without such trait, or making them take `Either<ExprId, PatId>` in place of `PatId`.
in case this is merged:
Closes#11532Closes#11839Closes#12322
fix: Improve proc macro errors a bit
Distinguish between
- there is no build data (for some reason?)
- there is build data, but the cargo package didn't build a proc macro dylib
- there is a proc macro dylib, but it didn't contain the proc macro we expected
- the name did not resolve to any macro (this is now an
unresolved_macro_call even for attributes)
I changed the handling of disabled attribute macro expansion to
immediately ignore the macro and report an unresolved_proc_macro,
because otherwise they would now result in loud unresolved_macro_call
errors. I hope this doesn't break anything.
Also try to improve error ranges for unresolved_macro_call / macro_error
by reusing the code for unresolved_proc_macro. It's not perfect but
probably better than before.
Distinguish between
- there is no build data (for some reason?)
- there is build data, but the cargo package didn't build a proc macro dylib
- there is a proc macro dylib, but it didn't contain the proc macro we expected
- the name did not resolve to any macro (this is now an
unresolved_macro_call even for attributes)
I changed the handling of disabled attribute macro expansion to
immediately ignore the macro and report an unresolved_proc_macro,
because otherwise they would now result in loud unresolved_macro_call
errors. I hope this doesn't break anything.
Also try to improve error ranges for unresolved_macro_call / macro_error
by reusing the code for unresolved_proc_macro. It's not perfect but
probably better than before.
fix: doc_links link type - Determine link type at start (fixes#12601)
fixes#12601
Looked like autolink/inline mismatch happened because end_link_type was parsed from the Text/Code events.
I changed it to be determined from the Start event, which should hopefully remain accurate while staying true to the cases where link type may need to be changed, according to the comment
```
// normally link's type is determined by the type of link tag in the end event,
// however in some cases we want to change the link type, for example,
// `Shortcut` type doesn't make sense for url links
```
Hopefully this is the desired behavior?
- remove Valid, it serves no purpose and just obscures the diff
- rename some things
- don't use is_valid_candidate when searching for impl, it's not necessary
fix: Only apply `cfg(test)` for local crates
Don't analyze dependencies with `test`; this should fix various cases where crates use `cfg(not(test))` and so we didn't find things.
"Local" here currently means anything that's not from the registry, so anything inside the workspace, but also path dependencies. So this isn't perfect, and users might still need to use `rust-analyzer.cargo.unsetTest` for these in some cases.
Don't analyze dependencies with `test`; this should fix various cases
where crates use `cfg(not(test))` and so we didn't find things.
"Local" here currently means anything that's not from the registry, so
anything inside the workspace, but also path dependencies. So this isn't
perfect, and users might still need to use
`rust-analyzer.cargo.unsetTest` for these in some cases.
fix: local items should not be completed in parent signature
fixes#11959
> We get a Bar completion for the following snippet which is wrong as the item is not visible in that position.
> ``` rust
> fn foo() -> $0 {
> struct Bar;
> }
> ```
I investigated the problem and found that the scope of the cursor offset, also `CompletionContext.scope` is the body of the function
fix methods in pub trait generated by macro cannot be completed
Fix#12483
Check if the container is trait and inherit the visibility to associate items during collection.
fix: Pass the build data to rustc_private crates
With this all proc-macros should resolve in rustc now when setting up the build script running command properly.
fix: #12441 False-positive type-mismatch error with generic future
I think the reason is same with #11815.
add ```Sized``` bound for ```AsyncBlockTypeImplTrait```.
Order auto-imports by relevance
Fixes#10337.
Basically we sort the imports according to how "far away" the imported item is from where we want to import it to. This change makes it so that imports from the current crate are sorted before any third-party crates. Additionally, we make an exception for builtin crates (`std`, `core`, etc.) so that they are sorted before any third-party crates.
There are probably other heuristics that should be added to improve the experience (such as preferring imports that are common elsewhere in the same crate, and ranking crates depending on the dependency graph). However, I think this is a first good step.
PS. This is my first time contributing here, so please be gentle if I have missed something obvious :-)
feature: `Merge imports` assist can merge multiple selected imports.
The selected imports have to have a common prefix in paths.
Select imports or use trees to merge:
```rust
$0use std::fmt::Display;
use std::fmt::Debug;
use std::fmt::Write;$0
```
Apply `Merge imports`:
```rust
use std::fmt::{Display, Debug, Write};
```
Closes#12426
The selected imports have to have a common prefix in paths.
Before
```rust
$0use std::fmt::Display;
use std::fmt::Debug;$0
```
After
```rust
use std::fmt::{Display, Debug};
```
fix(extract_module) resolving import panics and improve import resolution
- Should solve #11766
- While adding a test case for this issue, I observed another issue:
For this test case:
```rust
mod x {
pub struct Foo;
pub struct Bar;
}
use x::{Bar, Foo};
$0type A = (Foo, Bar);$0
```
extract module should yield this:
```rust
mod x {
pub struct Foo;
pub struct Bar;
}
use x::{};
mod modname {
use super:❌:Bar;
use super:❌:Foo;
pub(crate) type A = (Foo, Bar);
}
```
instead it gave:
```rust
mod x {
pub struct Foo;
pub struct Bar;
}
use x::{};
mod modname {
use x::Bar;
use x::Foo;
pub(crate) type A = (Foo, Bar);
}
```
So fixed this problem with second commit
