fix: bug in extract_function.rs
There is a little bug in extract_function: It appends `use path::to::ControlFlow;` if the function created contains string "ControlFlow".
A case below (also in the test named `does_not_import_control_flow` which will fail in the original code)
<img width="322" alt="image" src="4b80bb58-0cfd-4d56-b64c-d9649eed336e">
<img width="391" alt="image" src="3d7262f4-8a4c-44ea-822d-304b8b23fe28">
Now I have changed the condition determining whether adding import statement. Only when the new function body contains ControlFlow::Break or ControlFlow::Continue can the import statement be added.
Last related PR: https://github.com/rust-lang/rust-analyzer/pull/10309
internal: Migrate assists to the structured snippet API, part 4
Continuing from #15260
Migrates the following assists:
- `add_turbo_fish`
- `add_type_ascription`
- `destructure_tuple_binding`
- `destructure_tuple_binding_in_subpattern`
I did this a while ago, but forgot to make a PR for the changes until now. 😅
Due to the way the current tree mutation api works, we need to collect
changes before we can apply them to the real syntax tree, and also can only
switch to a file once.
`destructure_tuple_binding_in_sub_pattern` also gets migrated even
though can't be used.
feat: implement tuple return type to tuple struct assist
This PR implements the `convert_tuple_return_type_to_struct` assist, for converting the return type of a function or method from a tuple to a tuple struct. Additionally, it moves the `to_camel_case` and `char_has_case` functions from `case_conv` to `stdx` so that they can be used similar to `to_lower_snake_case`.
[tuple_return_type_to_tuple_struct.webm](2803ff58-fde3-4144-9495-7c7c7e139075)
Currently, the assist puts the struct definition above the function, or above the nearest `impl` or `trait` if applicable and only rewrites literal tuples that are returned in the body of the function. Additionally, it only attempts to rewrite simple tuple pattern usages with the corresponding tuple struct pattern but does so across files and modules.
I think that this is sufficient for the majority of use cases but I could be wrong. One thing I'm still not sure how to approach is handling `Self` and generics/lifetimes in the tuple type to be extracted. I was thinking of either manually figuring out what lifetimes and generics are in scope and using them (sort of similar to the `generate_function` assist) or maybe using `ctx.sema.resolve_type` and `generic_params` on `hir::Type` but this seems to not deal with lifetimes.
Closes#14293
feat: add assist for applying De Morgan's law to `Iterator::all` and `Iterator::any`
This PR adds an assist for transforming expressions of the form `!iter.any(|x| predicate(x))` into `iter.all(|x| !predicate(x))` and vice versa.
[IteratorDeMorgans.webm](aad1a299-6620-432b-9106-aafd2a7fa9f5)
Closes#15694
