aaron.ballman added a comment. In D99861#2694605 <https://reviews.llvm.org/D99861#2694605>, @urnathan wrote:
> See also https://bugs.llvm.org/show_bug.cgi?id=46446. when I first fell into > this issue, I did think it was trying to save the token stream as this patch > is doing. Neat I thought :) although I'm a clang weenie, saving the tokens > is putting this into deferred-parse territory, which makes me nervous. FWIW, I've been stewing on the deferred parse issues with the approach from this patch because they make me nervous as well. Because `[[]]` attributes can have arbitrary token soup for their arguments and that includes arbitrary expressions, I worry that just giving the plugin author a bunch of tokens and saying "you deal with it" will only work for very trivial arguments. > Wouldn't it be better for the ParsedAttrInfo objects to determine whether and > how to parse their arguments. They could do so immediately, or save tokens, > or whatever on a per-attribute per-argument basis. Isn't that more flexible? > Add some ParsedAttrInfo defaults for the default cxx11, gnu & clang flavours > of attributes? I think this would be an improved approach over just replaying the tokens for the plugin to handle. I would hope that we'd be able to design something that handles the easy cases of passing a string literal, an integer value, an enumerated list of named values, etc so that plugin authors don't have to reinvent the wheel for basic needs. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D99861/new/ https://reviews.llvm.org/D99861 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
