Auto merge of #12676 - DorianListens:dscheidt/extract-fun-trait-impl, r=jonas-schievink
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.
Auto merge of #12662 - DorianListens:dscheidt/extract-function-duplicate-name, r=DorianListens
fix: Extract Function produces duplicate fn names
This change fixes #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.
Dorian Scheidt [Thu, 30 Jun 2022 17:17:19 +0000 (12:17 -0500)]
fix: Extract Function produces duplicate fn names
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.
Auto merge of #12680 - lowr:fix/12428-regression, r=Veykril
fix regressions on assignment expressions
This is a follow-up PR on #12428. I'm not sure if this is everything I overlooked, so if there are more things that are not right, we may want to revert #12428.
This should also fix the increase of the type mismatches and the unknown types in diesel in the [metrics](https://rust-analyzer.github.io/metrics/?start=2022-06-23&end=2022-07-01) introduced by #12428.
The regressions are:
- some coercions don't work in the ordinary (i.e. non-destructuring) assignments
In order for coercions on ADT fields instantiations to work, lhs type has to be known before inferring rhs. #12428 changed the inference order, making rhs inferred before lhs, breaking the coercion, so I restored the original inference mechanism for the ordinary assignments.
Note that this kind of coercion doesn't happen in destructuring assigments, because when they are desugared, the struct expression is first assigned to a temporary, which is then assigned to the assignee, which is not coercion site anymore.
- type mismatches on individual identifiers are not reported
Auto merge of #12668 - Veykril:mac-source-map, r=Veykril
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"](https://github.com/rust-analyzer/ungrammar/commit/143cc528b11290bf2463de1fb5a97a15f9b2ed44), so I left it for the larger refactoring in the future and put a FIXME note.
bors [Thu, 30 Jun 2022 14:51:58 +0000 (14:51 +0000)]
Auto merge of #12634 - iDawer:match-check.witnesses, r=flodiebold
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.
bors [Thu, 30 Jun 2022 09:14:12 +0000 (09:14 +0000)]
Auto merge of #12428 - lowr:experimental/destructuring-assignment, r=flodiebold
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 :wink:) 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 #11532
Closes #11839
Closes #12322
bors [Fri, 24 Jun 2022 12:27:59 +0000 (12:27 +0000)]
Auto merge of #12629 - flodiebold:proc-macro-error-improvement, r=Veykril
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.
Florian Diebold [Fri, 24 Jun 2022 11:03:13 +0000 (13:03 +0200)]
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.
bors [Thu, 23 Jun 2022 23:15:33 +0000 (23:15 +0000)]
Auto merge of #12605 - erhuve:fix/determine-doc-link-type-at-start, r=erhuve
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?
projects / rust.git / log