respect magic trailing commas in return types #3916
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes #3018
I started out with modifying
left_hand_split
, doing a comprehensive rewrite of it to fully handle all manner of possible cases (see the length of the test file). But after reading more of the existing source code I started realizing that I was duplicating functionality, and in fact the only real thing that needed fixing was making sure thatright_hand_split
was applied to the function definition first when there's a trailing comma.I also found a bug in the string splitting of return type and attempted to fix that at the same time ... but I ended up concluding that it's probably better solved in a separate PR (if at all, who even writes their return types like that??) with a very different approach.
I think there's a couple cases that can get improved, mainly cases like:
would look much better if split on the right hand first. Detecting it also isn't terribly complicated ("split on rhs if the return type is longer than the param list"), I had it working in my original solution that rewrote left_hand_split.
Ended up doing some code duplication due to
bracket_split_build_line
having the side effect of normalizing the indent, which led tofoo def() ->int: ...
. There's maybe better solutions doing stuff like adding adont_normalize
parameter to it.Checklist - did you ...
CHANGES.md
if necessary?