[clang] Pass LangOpts from CompilerInstance to DependencyScanningWorker (PR #93753)

[Aaron Ballman via cfe-commits]

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