Previously, when triggering a method extraction from within an impl trait block, then this would always create a new impl block for
the struct, even if there already is one. Now, if there is already an existing trait-less impl block, then it'll put the extracted method in there.
**Caveats**:
- It currently requires the target impl block to be non-empty. This limitation is because the current architecture takes a `node_to_insert_after` as reference for where to insert the extracted function. An empty impl block doesn't have such a reference node, since it's empty. It seems that supporting this requires a much larger and more complex change.
- This is my first contribution in rust, so apologies for any beginner mistakes.
bors [Wed, 2 Nov 2022 11:06:54 +0000 (11:06 +0000)]
Auto merge of #13527 - unexge:use-let-else-stmt-in-convert-to-guarded-return-assist, r=jonas-schievink
Use let-else statements in `Convert to guarded return` assist
Follow up for https://github.com/rust-lang/rust-analyzer/pull/13516, addresses remaining part of https://github.com/rust-lang/rust-analyzer/issues/13254#issuecomment-1250408527
bors [Wed, 2 Nov 2022 10:50:08 +0000 (10:50 +0000)]
Auto merge of #13359 - feniljain:feat-must-use-option, r=Veykril
feat: add config for inserting must_use in `generate_enum_as_method`
Should fix #13312
Didn't add a test because I was not sure on how to add test for a specific configuration option, tried to look for the usages for other `AssistConfig` variants but couldn't find any in `tests`. If there is a way to test this, do point me towards it.
I tried to extract the formatting string as a common `template_string` and only have if-else for that, but it didn't compile :(
Also it seems these tests are failing:
```
test config::tests::generate_config_documentation ... FAILED
test config::tests::generate_package_json_config ... FAILED
```
Can you also point me to how to correct these 😅 ( I guess there is some command to automatically generate these? )
bors [Wed, 2 Nov 2022 10:15:18 +0000 (10:15 +0000)]
Auto merge of #13517 - feniljain:fix_completions, r=Veykril
fix: make custom expr prefix completions to understand refs
Possible fix of #7929
While reviewing the postfix completion code I saw that while calling `add_custom_postfix_completions` we were doing it under the part where reference was not taken into consideration, but as we are only adding postfix completions with `Expr` scope ( [source](https://github.com/rust-lang/rust-analyzer/blob/ba28e19b7838e3ad4223ae82d074dc3950ef1548/crates/ide-completion/src/completions/postfix.rs#L272) )
I shifted the `add_custom_postfix_completions` call to part where references are considered
I am not sure if this is the correct fix or I am understanding the problem exactly but this small move seemed to have fixed the issue :)
bors [Tue, 1 Nov 2022 17:01:07 +0000 (17:01 +0000)]
Auto merge of #13525 - jonas-schievink:generic-call-signature, r=jonas-schievink
feat: show signature help when calling generic types implementing `FnOnce`
This queries chalk for the `FnOnce` impl of callees and takes argument and return types from there, making generic `Callable`s available to the IDE. This makes signature help work for them, and potentially allows other features to take generic callables into account in the future.
bors [Mon, 31 Oct 2022 15:39:20 +0000 (15:39 +0000)]
Auto merge of #13523 - lowr:fix/adjust-expectation-for-if, r=lnicola
fix: disregard type variable expectation for if expressions
Fixes #13522
As [the comment](https://github.com/rust-lang/rust-analyzer/blob/8142d1f606dc2e52b1d2b8992671e2bd73379f28/crates/hir-ty/src/infer.rs#L1087-L1090) on `Expectation::adjust_for_branches` explains:
> If the expected type is just a type variable, then don't use an expected type. Otherwise, we might write parts of the type when checking the 'then' block which are incompatible with the 'else' branch.
Note that we already use it in match expressions. I've added tests for them too nevertheless.
bors [Sat, 29 Oct 2022 08:54:14 +0000 (08:54 +0000)]
Auto merge of #13505 - lowr:feat/gats, r=flodiebold
Clean up tests and add documentation for GATs related stuff
This is a follow-up PR for #13494.
- addresses https://github.com/rust-lang/rust-analyzer/pull/13494#discussion_r1006774897
- documents the ordering constraint on `Binders` and `Substitution` (which is not really follow-up for the previous PR, but it was introduced to support GATs and I strongly feel it's worth it)
bors [Thu, 27 Oct 2022 12:37:50 +0000 (12:37 +0000)]
Auto merge of #13494 - lowr:feat/gats, r=flodiebold
feat: type inference for generic associated types
This PR implements type inference for generic associated types. Basically, this PR lowers generic arguments for associated types in valid places and creates `Substitution`s for them.
I focused on the inference for correct Rust programs, so there are cases where we *accidentally* manage to infer things that are actually invalid (which would then be reported by flycheck so I deem them non-fatal). See the following tests and FIXME notes on them: `gats_with_dyn`, `gats_with_impl_trait`.
The added tests are rather arbitrary. Let me know if there are cases I'm missing or I should add.
When finding matching impl for a trait method, we've been testing the unifiability of self type. However, there can be multiple impl of a trait for the same type with different generic arguments for the trait. This patch takes it into account and tests the unifiability of all type arguments for the trait (the first being the self type) thus enables rust-analyzer to find the correct impl even in such cases.
bors [Sat, 22 Oct 2022 21:52:04 +0000 (21:52 +0000)]
Auto merge of #13466 - Veykril:invocation-location, r=Veykril
Implement invocation location config
This allows setting the working directory for build-scripts on flycheck
Complements https://github.com/rust-lang/rust-analyzer/pull/13128
This will be followed up by one more PR that adds a few simple interpolation vars for `overrideCommand`, with that we should cover the needs for most build systems I believe.
bors [Sat, 22 Oct 2022 15:49:00 +0000 (15:49 +0000)]
Auto merge of #13463 - lowr:fix/builtin-derive-with-const-generics, r=Veykril
Support const generics for builtin derive macro
Fixes #13121
We have been treating every generic parameter as type parameter during builtin derive macro expansion. This patch adds support for const generics in such expansions.
projects / rust.git / log