Sirraide wrote: > I think there are circumstances where the preprocessor may emit tokens that, > if run through the preprocessor again, will produce _different_ tokens. e.g.,
Yes, if you preprocess twice then you will expand macros twice and things that wouldn't have been recognised as directives might be; that's not great either, but that's an orthogonal problem that we'd want something like `-fpreprocessed` for. > IMO the 'correct' way ahead is "name-value pair" type pragma. IF it errors if > it is not the `__GLIBCXX__` (or w/e), and if the value is a non-integer, that > is still perfectly acceptable. I’m fine w/ that too. The original approach was that the macro would define `__GLIBCXX__` rather than set the value directly, so we could go with that instead. That said, I would suggest that this pragma _not_ care about things like `#undef`, warnings about unused macros, or `#pragma clang final`—because essentially, users should never be writing this pragma; and conversely, any compiler-generated uses should involve only macros that are reserved by the implementation (and a user doing anything like `#undef` to those would be UB anyway). I also don’t see `_MSC_VER` or `__GLIBCXX__` being redefined halfway through the TU (and even if `__GLICXX__` were to be redefined like that, our current infrastructur for the workarounds wouldn’t account for that since it just computes the value once and then caches is), so I don’t think we need to care about this case. https://github.com/llvm/llvm-project/pull/210802 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
