AaronBallman wrote: > > > Similarly, ObjC selector components exist outside of the normal keyword > > > rules, and the warning should never kick in on them. > > > > > > I don't know about selectors all that much; can you give me a test case > > that you think I should handle? > > In general: look at `ParseObjCSelectorPiece` and how it generally accepts > keywords in the selector. Actually, the list of keywords there seems out of > date and notably doesn't include post-C++98 keywords like `decltype`. The > logic is absolutely meant to encompass every keyword; note that it even > includes basic C keywords like `if` and `struct`. You probably don't want to > fix that, but I can ping someone at Apple to do it. > > Anyway, selectors show up in three places in the ObjC grammar: > > * `@selector` expressions, e.g. `@selector(virtual:typeid:bool:)` > > * message send expressions, e.g. `[obj virtual: 0 typeid: 0 bool: 0]` > > * method declarations, e.g. ` > > * declarations, e.g. > > > ``` > @interface Foo > - (void) virtual: (int) x typeid: (int) y bool: (int) z; > @end > ``` > > But there are also some special-case parsing rules for `class` because it is > an important property name for `NSObject`. For example, in Objective-C++, the > member name following `-> ` or `.` is allowed to be `class` despite it being > a keyword.
Ooof, it seems like there may not be a good way of handling this with the approach recommended by @zygoloid where we diagnose from `HandleIdentifier()` in the preprocessor. That requires far too much looking around to try to identify whether we're in the middle of a selector or not. The best I could think of would be to use some sort of "don't complain about keyword compatibility, we're doing <things>" RAII object to set a flag on the preprocessor so we can read it in `HandleIdentifier`. If we go that route, I could also stop looking to see if the preceding token is `@` from `HandleIdentifier()` and just use that mode. But is this too much of a hack? https://github.com/llvm/llvm-project/pull/137234 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
