Doesn't resolve the shadowing issues though, fixing those is gonna be really tricky I believe unless we can come up with a nice scheme to "order" item tree items (using syntax ranges and file ids would be a pain and also a bad idea since that'll require us to potentially reparse files in collection).
Auto merge of #12539 - soruh:instanciate_empty_structs, r=Veykril
Automatically instaciate trivially instaciable structs in "Generate new" and "Fill struct fields"
As proposed in #12535 this PR changes the "Generate new" and "Fill struct fields" assist/diagnostic to instanciate structs with no fields and enums with a single empty variant.
For example:
```rust
pub enum Bar {
Bar {},
}
struct Foo<T> {
a: usize,
bar: Bar,
_phantom: std::marker::PhantomData<T>,
}
impl<T> Foo<T> {
/* generate new */
Auto merge of #12775 - flodiebold:syntax-fixup-if, r=flodiebold
fix: Improve syntax fixup a bit, handle incomplete `if`
- allow appending tokens after a token, not just a node
- allow inserting delimiters (and remove them again)
- fix up `if {}` and `if` without anything following
Improve syntax fixup a bit, handle incomplete `if`
- allow appending tokens after a token, not just a node
- allow inserting delimiters (and remove them again)
- fix up `if {}` and `if` without anything following
Looking at this holistically, I don't fully understand *why* we need an
action here? Seems like we can just use rustup? nowadays github runners
come with rustup pre-installed.
Looking at this holistically, I don't fully understand *why* we need an
action here? Seems like we can just use rustup? nowadays github runners
come with rustup pre-installed.
Looking at this holistically, I don't fully understand *why* we need an
action here? Seems like we can just use rustup? nowadays github runners
come with rustup pre-installed.
Auto merge of #12556 - DorianListens:dscheidt/generic-extract, r=Veykril
fix: Support generics in extract_function assist
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.
I've never contributed to this project before, but I did try to follow the style guide. I believe that this change represents an improvement over the status quo, but I think it's also fair to argue that it doesn't fully "fix" the linked issue. I'm totally open to merging this as is, or going further to try to make a more complete solution. Also: if there are other unit or integration tests I should add, please let me know where to look!
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.