We *probably* should actually use the same machinery here, as we do
for fill match arms, but just special-casing options and results seems
to be a good first step.
The fix is admittedly quit literally just papering over.
Long-term, I see two more principled approaches:
* we switch to a fully tree-based impl, without parse . to_string
step; with this approach, there shouldn't be any panics. The results
might be nonsensical, but so was the original input.
* we preserve the invariant that re-parsing constructed node is an
identity, and make all the `make_xxx` method return an `Option`.
closes#4044
This fixes the a bug when merging imports from the second line when it already has a comma it would previously insert a comma.
There's probably a better way to check for a COMMA.
This also ends up with a weird indentation, but rust-fmt can easily deal with it so I'm not sure how to resolve that.
Closes#3832
3925: Implement assist "Reorder field names" r=matklad a=geoffreycopin
This PR implements the "Reorder record fields" assist as discussed in issue #3821 .
Adding a `RecordFieldPat` variant to the `Pat` enum seemed like the easiest way to handle the `RecordPat` children as a single sequence of elements, maybe there is a better way ?
Co-authored-by: Geoffrey Copin <copin.geoffrey@gmail.com>
todo!() "Indicates unfinished code" (https://doc.rust-lang.org/std/macro.todo.html)
Rust documentation provides further clarification:
> The difference between unimplemented! and todo! is that while todo!
> conveys an intent of implementing the functionality later and the
> message is "not yet implemented", unimplemented! makes no such claims.
todo!() seems more appropriate for assists that insert missing impls.
