mirror of
https://github.com/rust-lang/rust-analyzer
synced 2025-01-13 05:38:46 +00:00
43af7920af
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> |
||
|---|---|---|
| .. | ||
| base_db | ||
| cfg | ||
| flycheck | ||
| hir | ||
| hir_def | ||
| hir_expand | ||
| hir_ty | ||
| ide | ||
| ide_assists | ||
| ide_completion | ||
| ide_db | ||
| ide_diagnostics | ||
| ide_ssr | ||
| limit | ||
| mbe | ||
| parser | ||
| paths | ||
| proc_macro_api | ||
| proc_macro_srv | ||
| proc_macro_test | ||
| profile | ||
| project_model | ||
| rust-analyzer | ||
| sourcegen | ||
| stdx | ||
| syntax | ||
| test_utils | ||
| text_edit | ||
| toolchain | ||
| tt | ||
| vfs | ||
| vfs-notify | ||