AaronBallman wrote: > It was also brought up separately that the 'balanced token sequence' rule is > very simply to make parsing 'simpler' for many implementations. Since we > DON'T require it to simplify, I think making our parser 'more complex' for > this is a bad idea. I am very much leaning towards us just rejecting this, I > don't see any added value here.
There's an argument to be made that we should diagnose this for conformance reasons because the grammar for attribute argument lists requires balanced tokens, and so this is a syntax error. In C++, GCC, MSVC, and EDG all diagnose: https://godbolt.org/z/vxWrGq95K (C compilers that support C23, like SDCC, also diagnose). That said, I worry this will negatively impact compile time performance for very little benefit. There are a *lot* of unknown attributes in the wild which accept arguments and I think unbalanced tokens come up far, far more rarely. So if we were going down this route, I think I'd want `SkipUntil` to take some sort of flag to check for balanced tokens, but we should also do some timing tests on https://llvm-compile-time-tracker.com/ to see what the performance impact is... but I'm not certain if any of the test corpuses make heavy use of `[[]]` attributes; I think maybe only Clang uses them (and pretty sparingly), so I'm not certain what the best way to test the performance impacts will be. https://github.com/llvm/llvm-project/pull/220259 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
