Fix inference when pattern matching a tuple field with a wildcard
This should fix the following issue: https://github.com/rust-lang/rust-analyzer/issues/12331
* Replaced the `err_ty` in `infer_pat()` with a new type variable.
* Had to change the iterator code a bit, to get around multiple mutable borrows of `self` in `infer_pat()`.
Also added a test
* Also added a test
Generate enum variant assist
So, this is kind of a weird PR!
I'm a complete newcomer to the `rust-analyzer` codebase, and so I browsed the "good first issue" tag, and found #11635. Then I found two separate folks had taken stabs at it, most recently `@maartenflippo` — and there had been a review 3 days ago, but no activity in a little while, and the PR needed to be rebased since the crates were renamed from `snake_case` to `kebab-case`.
So to get acquainted with the codebase I typed this PR by hand, looking at the diff in #11995, and I also added a doc-test (that passes).
I haven't taken into account the comments `@Veykril` left in #11995, but I don't want to steal any of `@maartenflippo's` thunder! Closing this PR is perfectly fine. Or Maarten could use it as a "restart point"? Or I could finish it up, whichever feels best to everyone.
I think what remains to be done in this PR, at least, is:
* [x] Only disable the "generate function" assist if the name is `PascalCase`
* [x] Only enable the "generate variant" assistant if the name is `PascalCase`
* [x] Simplify with `adt.source()` as mentioned here: https://github.com/rust-lang/rust-analyzer/pull/11995#discussion_r875134175
* [ ] Add more tests for edge cases? Are there cases where simply adding one more indent level than the enum's indent level is not good enough? Some nested trickery I'm not thinking of right now?
Anyway. This PR can go in any direction. You can tell me "no, tackle your own issue!" And I'll go do that and still be happy I got to take a look at rust-analyzer some by doing this. Or you can tell me "okay, now _you_ finish it", and I guess I'll try and finish it :)
Closes#11635
Increase defalt chalk overflow depth to match max solver size
TBC:
- #12279: ok above 480
- ~~#12182~~
- ~~#12095~~
- #11902: ok above 350
- ~~#11668~~
- #11370: ok above 450
- #9754: probably ok above 250 (!), and the code in cause and branch are gone
Closes#12279Closes#11902Closes#11370Closes#9754
Only advertise this feature in the server capabilities when the client
supports SnippetTextEdit.
Close#11398.
Co-authored-by: unexge <unexge@gmail.com>
This also disables "generate function" when what we clearly want is to
generate an enum variant.
Co-authored-by: Maarten Flippo <maartenflippo@outlook.com>
feat: Revert the "Add attribute" assist
Reverts https://github.com/rust-lang/rust-analyzer/pull/12296, as the added indirection and "assist noise" (the assist has to trigger inside the body of an item to match what the "Add `#[derive]`" does) makes this not really pull its weight over just using attribute completions.
Keeps the changes to "Add getter". `#[must_use]` can be applied using the attribute completions.
feat: hide type inlay hints for initializations of closures
This PR adds an option to hide the inlay hints for `let IDENT_PAT = CLOSURE_EXPR;`, which is a somewhat common coding pattern. Currently the inlay hints for the assigned variable and the closure expression itself are both displayed, making it rather repetitive.
In order to be consistent with closure return type hints, only closures with block bodies will be hid by this option.
Personally I'd feel comfortable making it always enabled (or at least when closure return type hints are enabled), but considering the precedent set in #10761, I introduced an off-by-default option for this.
changelog feature: option to hide type inlay hints for initializations of closures
Config revamp
Fixes https://github.com/rust-lang/rust-analyzer/issues/11790
Fixes https://github.com/rust-lang/rust-analyzer/issues/12115
This PR changes a lot of config names, and a few ones are being merged or split apart. The reason for this is that our configuration names currently are rather inconsistent and some where poorly chosen in regards to extensability. This PR plans to fix that.
We still allow the old config names by patching them to the new ones before deserializing to keep backwards compatability with other clients (the VSCode client will auto update the config) but ideally we will get rid of that layer in the future.
Here is a list of the changes:
These are simple renames `old_name | alias1 | alias2 ... -> new_name` (the vscode client will fix these up automagically):
```
assist_allowMergingIntoGlobImports -> imports_merge_glob
assist_exprFillDefault -> assist_expressionFillDefault
assist_importEnforceGranularity -> imports_granularity_enforce
assist_importGranularity | assist_importMergeBehavior | assist_importMergeBehaviour -> imports_granularity_group
assist_importGroup -> imports_group_enable
assist_importPrefix -> imports_prefix
cache_warmup -> primeCaches_enable
cargo_loadOutDirsFromCheck -> cargo_buildScripts_enable
cargo_runBuildScripts | cargo_runBuildScriptsCommand -> cargo_runBuildScripts_overrideCommand
cargo_useRustcWrapperForBuildScripts -> cargo_runBuildScripts_useRustcWrapper
completion_snippets -> completion_snippets_custom
diagnostics_enableExperimental -> diagnostics_experimental_enable
experimental_procAttrMacros -> procMacro_attributes_enable
highlighting_strings -> semanticHighlighting_strings_enable
highlightRelated_breakPoints -> semanticHighlighting_breakPoints_enable
highlightRelated_exitPoints -> semanticHighlighting_exitPoints_enable
highlightRelated_yieldPoints -> semanticHighlighting_yieldPoints_enable
highlightRelated_references -> semanticHighlighting_references_enable
hover_documentation -> hover_documentation_enable
hover_linksInHover | hoverActions_linksInHover -> hover_links_enable
hoverActions_debug -> hoverActions_debug_enable
hoverActions_enable -> hoverActions_enable_enable
hoverActions_gotoTypeDef -> hoverActions_gotoTypeDef_enable
hoverActions_implementations -> hoverActions_implementations_enable
hoverActions_references -> hoverActions_references_enable
hoverActions_run -> hoverActions_run_enable
inlayHints_chainingHints -> inlayHints_chainingHints_enable
inlayHints_closureReturnTypeHints -> inlayHints_closureReturnTypeHints_enable
inlayHints_hideNamedConstructorHints -> inlayHints_typeHints_hideNamedConstructorHints
inlayHints_parameterHints -> inlayHints_parameterHints_enable
inlayHints_reborrowHints -> inlayHints_reborrowHints_enable
inlayHints_typeHints -> inlayHints_typeHints_enable
lruCapacity -> lru_capacity
runnables_cargoExtraArgs -> runnables_extraArgs
runnables_overrideCargo -> runnables_command
rustcSource -> rustc_source
rustfmt_enableRangeFormatting -> rustfmt_rangeFormatting_enable
```
These are configs that have been merged or split apart, which have to be manually updated by the user:
```
callInfo_full -> signatureInfo_detail, signatureInfo_documentation_enable
cargo_allFeatures, cargo_features -> cargo_features
checkOnSave_allFeatures, checkOnSave_features -> checkOnSave_features
completion_addCallArgumentSnippets completion_addCallParenthesis -> completion_callable_snippets
```
Remove handling of `#[rustc_deprecated]`
This should be merged along with rust-lang/rust#95960.
Because the attribute still exists in rustc, I've left the definition here. With that said, any use of it is an error, so I've removed any handling of `#[rustc_deprecated]`.
