-
Couldn't load subscription status.
- Fork 461
[SwiftParse] Update for accessor block disambiguation marker #3171
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
[SwiftParse] Update for accessor block disambiguation marker #3171
Conversation
|
swiftlang/swift#84972 |
03553e8 to
f5c167e
Compare
|
swiftlang/swift#84972 |
Sources/SwiftParser/Lookahead.swift
Outdated
| if lookahead.peek(isAt: .identifier), | ||
| lookahead.peek().tokenText == "_accessorBlock" | ||
| { | ||
| return true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| return true; | |
| return true |
| lookahead.eat(.leftBrace) | ||
|
|
||
| // '@_accessorBlock' is a builtin disambiguation marker. | ||
| if lookahead.peek(isAt: .identifier), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don’t you also need to consume the @ before looking at the identifier? Also, I think a test case would be good.
Also, I think this would probably belong in the while lookahead.consume(if: .atSign) != nil { loop below to make it resilient so @_accessorBlock doesn’t necessarily need to be the first attribute.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don’t you also need to consume the @ before looking at the identifier?
We know the current token is @ at line 269 above.
I think this would probably belong in the while lookahead.consume(if: .atSign) != nil { loop below to make it resilient so @_accessorBlock doesn’t necessarily need to be the first attribute.
ASTPrinter only print @_accessorBlock right after {. I don't see a reason to put it in the loop
Also, I think a test case would be good.
Sure, I will add a test case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We know the current token is
@at line 269 above.
Ah, I got a little confused about nextToken and then using a fresh lookahead here. Opened #3172 to make this slightly easier to read.
ASTPrinteronly print@_accessorBlockright after{. I don't see a reason to put it in the loop
OK, your choice. But I find it odd that order of attributes matters here when it doesn’t in any other cases.
I think the guard is a lot easier to read here, noticed while reviewing swiftlang#3171.
If the block after an pattern binding initializer starts with
`{ @_accessorBlock` it's an accessor block, not a trailing closure.
rdar://140943107
f5c167e to
efab59f
Compare
|
swiftlang/swift#84972 |
|
swiftlang/swift#84972 |
I think the guard is a lot easier to read here, noticed while reviewing swiftlang#3171.
I think the guard is a lot easier to read here, noticed while reviewing swiftlang#3171.
Update for swiftlang/swift#84972
If the block after a pattern binding initializer starts with
{ @_accessorBlockit's an accessor block, not a trailing closure.rdar://140943107