bors[bot] 43af7920af Merge #9871 ... 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>		2021-08-13 11:19:16 +00:00
..
src	Merge #9871	2021-08-13 11:19:16 +00:00
Cargo.toml	Use more strictly typed syntax nodes for analysis in extract_function assist	2021-07-29 17:26:37 +02:00