AaronBallman 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.
But the list of tokens depends on things like what features are enabled, right? e.g., `-fchar8_t` introduces a new keyword, while `_Atomic` isn't a keyword in OpenCL, and `bool` is only a keyword in C23 and later but is always a keyword in C++, etc. Ah, but in terms of dependency scanning, whether those are keywords or not probably doesn't matter? And because we expose things like `embed` as a keyword in all language modes, not just C23, the language standard doesn't matter either? > 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. Seems reasonable to me. 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
