-
Notifications
You must be signed in to change notification settings - Fork 440
Simplify consumption of prefixes in a token #1910
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -23,6 +23,13 @@ protocol TokenConsumer { | |
/// Consume the current token and change its token kind to `remappedTokenKind`. | ||
mutating func consumeAnyToken(remapping remappedTokenKind: RawTokenKind) -> Token | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we ever take a prefix where it's not just the default text of the token? Could we just pass the token in rather than the prefix as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, there’s and Good idea though, I added a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If they're the minority, could still be worth having a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is that this method doesn’t have a clearly defined meaning if |
||
/// Consumes a given token, or splits the current token into a leading token | ||
/// matching the given token and a trailing token and consumes the leading | ||
/// token. | ||
/// | ||
/// <TOKEN> ... -> consumePrefix(<TOK>) -> [ <TOK> ] <EN> ... | ||
mutating func consumePrefix(_ prefix: SyntaxText, as tokenKind: RawTokenKind) -> Token | ||
|
||
/// Synthesize a missing token with `kind`. | ||
/// If `text` is not `nil`, use it for the token's text, otherwise use the token's default text. | ||
mutating func missingToken(_ kind: RawTokenKind, text: SyntaxText?) -> Token | ||
|
@@ -137,6 +144,12 @@ extension TokenConsumer { | |
return nil | ||
} | ||
|
||
/// Whether the current token’s text starts with the given prefix. | ||
@inline(__always) | ||
mutating func at(prefix: SyntaxText) -> Bool { | ||
return self.currentToken.tokenText.hasPrefix(prefix) | ||
} | ||
|
||
/// Eat a token that we know we are currently positioned at, based on `at(anyIn:)`. | ||
@inline(__always) | ||
mutating func eat(_ handle: TokenConsumptionHandle) -> Token { | ||
|
@@ -248,6 +261,17 @@ extension TokenConsumer { | |
return nil | ||
} | ||
} | ||
|
||
/// If the current token starts with the given prefix, consume the prefis as the given token kind. | ||
/// | ||
/// Otherwise, return `nil`. | ||
mutating func consume(ifPrefix prefix: SyntaxText, as tokenKind: RawTokenKind) -> Token? { | ||
if self.at(prefix: prefix) { | ||
return consumePrefix(prefix, as: tokenKind) | ||
} else { | ||
return nil | ||
} | ||
} | ||
} | ||
|
||
// MARK: Convenience functions | ||
|
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.
Did you remove the recovery because you found it didn't actually work as expected?
I was expecting us to parse
protocol Test<Foo Bar> {}
mostly properly, ie. with justBar
as unexpected. But that doesn't happen as the>
in recovery is parsed as a postfix operator (not a right angle) and thus what actually happens is that we skip up to the{
. Did you decide it wasn't worth handling that 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.
Yes, I couldn’t find any examples where the recovery kicked in.
We certainly could have
expect(prefix:as:)
but it’s implementation is non-trivial because non of the current recovery infrastructure supports recovery a to somewhere inside a token. I filed #1923 and maybe we can implement it in a follow-up PR.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.
Thanks, I wonder if there's other cases where this is happening (ie. no recovery because we're looking for a prefix).
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.
That’s happening everywhere we currently expect a prefix. It would be nice to fix at some point.