This change attempts to resolve issue #7636: Extract into Function does not
create a generic function with constraints when extracting generic code.
In `FunctionBody::analyze_container`, we now traverse the `ancestors` in search
of `AnyHasGenericParams`, and attach any `GenericParamList`s and `WhereClause`s
we find to the `ContainerInfo`.
Later, in `format_function`, we collect all the `GenericParam`s and
`WherePred`s from the container, and filter them to keep only types matching
`TypeParam`s used within the newly extracted function body or param list. We
can then include the new `GenericParamList` and `WhereClause` in the new
function definition.
This change only impacts `TypeParam`s. `LifetimeParam`s and `ConstParam`s are
out of scope for this change.
Auto merge of #12742 - TonalidadeHidrica:fix-obsolete-config-keys, r=Veykril
Fix obsolete config keys
The config keys were drastically reorganized by #12010, but the docs don't reflect the updates, causing inconsistency and confusion. I checked for such obsolete configuration keys and updated to the new one. For reproducibility, I attach a small shell script that I used to examine the old keys. Now the script only detects `cargoExtraArgs` and `overrideCargo`, which originates from other type definition in the code but not from the configuration.
Auto merge of #12747 - jonas-schievink:proc-macro-abi-1.63, r=jonas-schievink
fix: Update 1.63 proc macro ABI to match rustc
This updates us to the ABI used by rustc 1.63.0-beta.5, which will likely be the ABI of the next stable Rust release. It should also work on nightly (for now, but future changes won't be supported until the rustc version is bumped).
cc https://github.com/rust-lang/rust-analyzer/issues/12600
Auto merge of #12727 - DorianListens:dscheidt/extract-var-field-name, r=jonas-schievink
fix: Improve suggested names for extracted variables
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.
fix: Improve suggested names for extracted variables
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.
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