cargo llvm-lines shows that path_to_error bloats the code. I don't think
I've needed this functionality recently, seems that we've fixed most of
the serialization problems. So let's just remove it. Should be easy to
add back if we ever need it, and it does make sense to keep the
`from_json` function around.
9896: internal: Only complete type annotations for patterns in function params r=Veykril a=Veykril
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9893: fix: Don't use uncached syntax nodes in `generate_function` for sema lookups r=Veykril a=Veykril
Fixes the crash in the comment here https://github.com/rust-analyzer/rust-analyzer/issues/9382#issuecomment-896101298
Couldn't make out a repro test for this unfortunately
still not idea about the original issue
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
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>
