This fixes rdar://30741878
Thanks!
Erik
Differential D50527
[Parser] Support alternative operator token keyword args in Objective-C++ erik.pilkington on Aug 9 2018, 12:35 PM. Authored by
Details This fixes rdar://30741878 Thanks!
Diff Detail Event TimelineComment Actions One comment, but otherwise the code change looks mechanically correct. Not accepting only because I don't know whether this is the intended language rule for Objective-C++ or not (please get someone else to sign off on that).
Comment Actions Remove isBinaryCXXAlternativeOperatorToken, this check can be done using OpToken.getAsIdentifierInfo(). Thanks! FWIW, I can't imagine this being anything but an oversight, we go out of our way to support these tokens in ParseObjCSelectorPiece, and we already happen to support unary alternative operators, such as [foo not]. Comment Actions Assuming you've done enough source-compatibility testing to say with reasonable confidence that this won't break anything, I think this is fine. It's a core goal of Objective-C/C++ to allow the base language as a complete subset if at all possible. Comment Actions I don't really see how this could break source-compatibility, I don't believe there is a way to start a binary operator's RHS with a colon[1] or a r_square, so this change can only affect programs that were previously ill-formed. I'll run some internal builds and report back though, just to be paranoid. [1] excluding the GNU conditional expr, which is handled because getIdentifierInfo will always return nullptr for '?'. Comment Actions If the build came back clean, then I think our combination of previous sign-offs is good enough. :) |
Just check Tok.getIdentifierInfo(). That will be null for a punctuation token and non-null for a token spelled as an identifier. (I don't think you even need the switch, because we already only get here for operators.)