AaronBallman wrote: > > > I guess the general question is - is it acceptable to have the Scanner > > > operating in a language standard different than the passed in language > > > mode and different than the compiler language standard? > > > > > > I think that is acceptable. It is kinda hacky, but the lexer and > > preprocessor are largely independent of the language and the standard. When > > they do depend on those settings, taking the union of the features and > > letting the compiler trim it down is still a perfectly sound thing to do. > > You can certainly construct cases where the different lexing rules in > different language modes allow you to detect which language you're in from > within the preprocessor ([1](https://eel.is/c++draft/diff.cpp11.lex) > [2](https://eel.is/c++draft/diff.cpp14.lex#2) > [3](https://eel.is/c++draft/diff.cpp03.lex#1)) or where enabling more > language mode flags may reject valid code. It may be good enough for what the > scanner is trying to do, but I think it's a stretch to say that it's sound.
+1; it's definitely not sound to go this approach, though it may work well enough in practice to be worth the tradeoff. That said, I think the behavior of the dependency scanner ignoring the language options used is actually kind of problematic, unless I'm misunderstanding something. This means command line options that impact dependency scanning may fail (for example, the user might enable SYCL or OpenMP on the command line and that may have different dependencies, trigraph support may be important for things like `??=include`, freestanding vs not impacts which preprocessor macros are predefined, etc. How do we handle that sort of stuff, or do we just ignore it? https://github.com/llvm/llvm-project/pull/93753 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
