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
Fix build on OpenBSD (and probably other BSDs too)
notify-5.0.0-pre.14 does not build on these systems; this was fixed in
41a74f0e98 , which landed in pre.15.
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
On typing handler for angle brackets(<) with snippets
I implemented my idea in #11398 in "cargo cult programming"-style without actually know what I'm doing, so feedback is welcome. The PR is split into two commits to ease the review. I used `@unexge's` original prototype, which forms the basis of the PR.
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: Add "cargo clippy" task preset
We've had a couple of common presets in `Tasks: Run Task -> cargo -> cargo [check,build,test,...]` before. This PR adds `cargo clippy` to that list, which makes for a convenient way of occasionally running Clippy on your code without having to reconfigure the Check on Save command to clippy.
These presets all use the `cargo` task type that we provide, so diagnostics will show up in the editor. However, they don't go through the server-side parsing logic, so it's not possible to apply suggestions, and diagnostics are fairly "low-fidelity". It would be cool if we could somehow pass Cargo's JSON output through the LSP server and render it properly, for arbitrary tasks.
cc https://github.com/rust-lang/rust-analyzer/issues/12323
