Ignore discretionary newlines in a number of new locations. #143
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- After the colon in...
- ...a type annotation (`x: Int`)
- ...a tuple type (`(a: A, b: B) -> Void`)
- ...a tuple expression element (`(x: 10, y: 20)`)
- ...a dictionary type (`[Key: Value]`)
- ...a dictionary element (`["key": "value"]`)
- ...a function call argument (`foo(x: 10, y: 20)`)
- ...a function declaration parameter (`func foo(x: Int)`)
- ...a generic parameter (`struct A<T: P> {}`)
- ...an availability attribute (`@attribute(renamed: "foo")`)
- Between the first and second name of a parameter in a function
declaration (`func foo(firstName secondName: Type)`)
- After the specifier in an attributed type (`inout Foo`)
We still allow wrapping in all of these locations, but only if the
formatter determines that it is necessary to make the contents fit.
|
cc @dylansturg |
dylansturg
reviewed
Feb 10, 2020
| @@ -1240,9 +1248,10 @@ fileprivate final class TokenStreamCreator: SyntaxVisitor { | |||
|
|
|||
| override func visit(_ node: TupleTypeElementSyntax) -> SyntaxVisitorContinueKind { | |||
| before(node.firstToken, tokens: .open) | |||
| after(node.colon, tokens: .break) | |||
| after(node.inOut, tokens: .break) | |||
There was a problem hiding this comment.
Do we need this break after the inOut token?
There was a problem hiding this comment.
The inOut token here is legacy, I believe, from when the attribute used to come before the variable name instead of the type (e.g., inout foo: Bar instead of foo: inout Bar). The parser doesn't accept that syntax anymore (I tried it in the syntax explorer), so I don't think this will ever be non-nil. When using the new syntax (foo: inout Bar), the type comes across as an AttributedTypeSyntax, and we add a break after the specifier (which might be inout, __shared, etc.).
| @@ -1303,7 +1312,7 @@ fileprivate final class TokenStreamCreator: SyntaxVisitor { | |||
|
|
|||
| override func visit(_ node: AvailabilityLabeledArgumentSyntax) -> SyntaxVisitorContinueKind { | |||
| before(node.label, tokens: .open) | |||
| after(node.colon, tokens: .break(.continue, size: 1)) | |||
| after(node.colon, tokens: .break(.continue, newlines: .elective(ignoresDiscretionary: true))) | |||
There was a problem hiding this comment.
This break had a size of 1 before, to create a space. Do we still want that space when it doesn't fire?
There was a problem hiding this comment.
The default size for a break is 1 (https://github.com/apple/swift-format/blob/master/Sources/SwiftFormatPrettyPrint/Token.swift#L210), so I was cleaning up the unnecessary specification while editing here.
We probably ought to do that throughout at some point. I also think we ought to make the break kind be explicit instead of defaulting to .continue.
dylansturg
approved these changes
Feb 10, 2020
dylansturg
added a commit
to dylansturg/swift-format
that referenced
this pull request
Mar 9, 2020
Reverted `ignoresDiscretionary` breaks include after the colon in... - a dictionary type - a dictionary element - a function call argument - a function decl parameter - a generic parameter - a tuple type - a tuple expr element
dylansturg
added a commit
to dylansturg/swift-format
that referenced
this pull request
Mar 9, 2020
Several breaks were changed to disallow discretionary newlines in swiftlang#143. In practice, some of these breaks actually require a more nuanced approach because grouping around the content after the `:` is frequently subjective. Depending on the length of the label/key before the `:` and the actual expr or type, it varies whether a group should be around the content after the `:`. The formatter's current model doesn't support modifying the tokens to add/remove group tokens once the token stream is created. In a future patch, it would be nice to have a way to switch between grouping and not grouping the content after the `:` based on the preceding key or label. Reverted `ignoresDiscretionary` breaks include after the colon in... - a dictionary type - a dictionary element - a function call argument - a function decl parameter - a generic parameter - a tuple type - a tuple expr element
dylansturg
added a commit
to dylansturg/swift-format
that referenced
this pull request
Mar 9, 2020
Several breaks were changed to disallow discretionary newlines in swiftlang#143. In practice, some of these breaks actually require a more nuanced approach because grouping around the content after the `:` is frequently subjective. Depending on the length of the label/key before the `:` and the actual expr or type, it varies whether a group should be around the content after the `:`. The formatter's current model doesn't support modifying the tokens to add/remove group tokens once the token stream is created. In a future patch, it would be nice to have a way to switch between grouping and not grouping the content after the `:` based on the preceding key or label. Reverted `ignoresDiscretionary` breaks include after the colon in... - a dictionary type - a dictionary element - a function call argument - a function decl parameter - a generic parameter - a tuple type - a tuple expr element
dylansturg
added a commit
to dylansturg/swift-format
that referenced
this pull request
Mar 9, 2020
Several breaks were changed to disallow discretionary newlines in swiftlang#143. In practice, some of these breaks actually require a more nuanced approach because grouping around the content after the `:` is frequently subjective. Depending on the length of the label/key before the `:` and the actual expr or type, it varies whether a group should be around the content after the `:`. The formatter's current model doesn't support modifying the tokens to add/remove group tokens once the token stream is created. In a future patch, it would be nice to have a way to switch between grouping and not grouping the content after the `:` based on the preceding key or label. Reverted `ignoresDiscretionary` breaks include after the colon in... - a dictionary type - a dictionary element - a function call argument - a function decl parameter - a generic parameter - a tuple type - a tuple expr element
allevato
added a commit
that referenced
this pull request
Mar 10, 2020
…iscretionary Restore some discretionary newlines from PR #143
aaditya-chandrasekhar
pushed a commit
to val-verde/swift-format
that referenced
this pull request
May 20, 2021
Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](lodash/lodash@4.17.15...4.17.19) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Mattt <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
x: Int)(a: A, b: B) -> Void)(x: 10, y: 20))[Key: Value])["key": "value"])foo(x: 10, y: 20))func foo(x: Int))struct A<T: P> {})@attribute(renamed: "foo"))declaration (
func foo(firstName secondName: Type))inout Foo)We still allow wrapping in all of these locations, but only if the
formatter determines that it is necessary to make the contents fit.