Previously, we only inverted comparison operators (< and the like) if
the type implemented Ord. This doesn't make sense: if `<` works, then
`>=` will work as well!
Extra semantic checks greatly reduce robustness and predictability of
the assist, it's better to keep things simple.
9882: fix: Don't call deprecated `compile` regex method r=lnicola a=lnicola
Fixes#9872
It looks like `compile` expects to be called like `RegExp.compile("foo", "m")`, so calling `.compile()` on an existing regex replaces it with an empty one.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
9886: feat: type inference for if-let guards r=jonas-schievink a=jonas-schievink
This turned out fairly simple
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9871: Jump to generated func r=mahdi-frms a=rylev
Worked on this with `@yoshuawuyts.`
We thought we ran into an issue with the `generate_function` assist where the code was not being generated in a certain situations. However, it wasn't actually a bug just a very confusing implementation where the cursor is not moved to the newly generated function. This happened when the return type was successfully inferred (and not unit). The function would be generated, but selection would not be changed.
This can be very confusing: If the function is generated somewhat far from where the assist is being invoked, the user never sees that the code was generated (nor are they given the chance to actually implement the function body).
This PR makes it so that the cursor is _always_ moved to somewhere in the newly generated function. In addition, if we can infer unit as the type, then we do not still generate `-> ()` as the return type. Instead, we simply omit the return type.
This means the selection will move to either one of two places:
* A generated `-> ()` return type when we cannot successfully infer the return type.
* The `todo!()` body when we can successfully infer the return type.
Co-authored-by: Ryan Levick <me@ryanlevick.com>
9879: feat: Support `if let` match guards r=jonas-schievink a=jonas-schievink
Adds support for parsing and computing bindings for `if let` match guards (https://github.com/rust-lang/rust/issues/51114). Type inference support is still missing, but shouldn't be hard to add in a follow-up PR.
Closes https://github.com/rust-analyzer/rust-analyzer/issues/9876
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9874: fix: Always add implicit `proc_macro` dependency r=jonas-schievink a=jonas-schievink
Even crates that don't set `proc-macro = true` are allowed to depend on `proc_macro` (just none of the APIs work when called outside of a proc macro).
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9857
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9869: Use term "method" on label for generating method impl r=Veykril a=rylev
When showing the user the `generate_function` assist, use the term "method" when generating a method instead of the term "function" (which is correct but maybe not the most appropriate in that context).
Co-authored-by: Ryan Levick <me@ryanlevick.com>
9863: feat: Generate default trait fn impl when generating `PartialEq` r=yoshuawuyts a=yoshuawuyts
Implements a default trait function body when generating the `PartialEq` trait for a type. Thanks!
r? `@veykril`
Co-authored-by: Yoshua Wuyts <yoshuawuyts@gmail.com>
9854: internal: document that ascription is preferred to a turbo fish r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
9836: Refactor: quick clean-up of iteration idioms in the `vfs` crate r=matklad a=Some-Dood
This PR cleans up some of the iteration idioms used in the `vfs` crate. Most of the changes simply converted `for` loops into their `std::iter::Iterator`-method counterpart. Other changes required some inversion of logic to accommodate for better short-circuiting. Overall, there should be no behavioral changes. If there are any stylistic issues, I will gladly adhere to them and adjust the PR accordingly. Thanks!
Co-authored-by: Basti Ortiz <39114273+Some-Dood@users.noreply.github.com>
9828: Remove dependency on the system graphviz when rendering crate graph r=lnicola a=p32blo
This PR removes the need for having `graphviz` installed on the user system by using the `d3-graphviz` npm package.
The responsibility of rendering the svg output is moved to the extension while the rust side only handles the generation of the dot file.
This change also brings the following additional features:
- Allow zooming the view
- Ctrl+click to reset the zoom
- Adjust the color scheme to dark themes
- Works on any platform without installing graphviz locally
---
I’m not sure if this fits what you had in mind for the crates graph feature but I decided to submit it anyway to see if this is useful to anyone else.
A potential downside might be that it increases the extension size ( haven’t checked) but this feature already required the installation of graphviz on the user side, so the cost is just moved explicitly to the extension.
Feel free to make any suggestion or comments.
Co-authored-by: André Oliveira <p32blo@gmail.com>
