Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: Format for comprehension expressions #3916

Merged
merged 11 commits into from
May 9, 2023

Conversation

MikaelMayer
Copy link
Member

This PR fixes #3912
Specifically, I ensured that "in" and "<-" operator indent their second operator compared to the first, but if "<-" starts the line, then it indents its second argument only relative to itself.

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.

@MikaelMayer MikaelMayer requested a review from alex-chew April 27, 2023 18:25
@MikaelMayer MikaelMayer enabled auto-merge (squash) April 27, 2023 18:25
PartC,
j
<- PartD +
PartE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this PartE intended to be aligned with PartD, or is it supposed to be one 2-space indent past the corresponding <-?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is intended to be aligned with PartD. Specifically, the "<-" is treated like an "in" binary operator, and I put the rule that if the "in" operator is not followed by a newline, then it starts a new aligning indentation. If it is followed by a newline, then it's indented by two spaces as usual. This matches usages of newlines I've seen for the second argument of "in" and "<-"

alex-chew
alex-chew previously approved these changes May 4, 2023
Copy link
Contributor

@alex-chew alex-chew left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, aside from a question about the resulting formatting (not blocking)

@MikaelMayer MikaelMayer requested a review from alex-chew May 5, 2023 21:29
@MikaelMayer MikaelMayer added the release-blocker Must be resolved before the next release label May 5, 2023
alex-chew
alex-chew previously approved these changes May 5, 2023
alex-chew
alex-chew previously approved these changes May 8, 2023
@MikaelMayer MikaelMayer merged commit 298fbcb into master May 9, 2023
@MikaelMayer MikaelMayer deleted the fix-3912-formatter-collection-arrow branch May 9, 2023 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-blocker Must be resolved before the next release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Formater should have a continuation indent
2 participants