jansvoboda11 wrote: > > 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.
I'll defer this to @Bigcheese, I don't think we've hit any of these yet. > +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? This layer of the dependency scanner only lexes the source into a list of tokens. Preprocessing and dependency discovery happen later and do respect the command-line options. Good point on trigraphs. I think that's similar to the digit separator issue: we can unconditionally enable this feature on this layer of the dependency scanner and let the build fail later during compilation itself. 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
