AaronBallman wrote: This is a bit of a tricky situation. On the one hand, we want these interfaces to be generic and so we'd prefer something that's not limited to just a single attribute (or family of attributes). On the other hand, attribute arguments are a mess because they can contain balanced token soup rather than formal arguments. *Most* attributes have formal arguments we could support via a more generic interface, but we have outliers like `availability`: `void f(void) __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));` where the information isn't packaged into typical arguments.
I think a more general solution means having to invent an abstraction for "attribute argument" where you can get back something like a `CXAttrArg` object to represent one logical argument, and then have interfaces for interrogating the argument to get details out of it. For most attributes, that abstraction would be a thin wrapper around another cursor representing the expression or declaration (etc). For things more like token soup, I think we'd need specific accessors for just that attribute cursor kind. We wouldn't have to handle all kinds of arguments up front, just cover the 90% case. But it leaves the door open to supporting all argument kinds. WDYT? https://github.com/llvm/llvm-project/pull/113754 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
