[clang] [Serialization] Downgrade error to warning for inconsistent language flags (PR #117840)

[Chuanqi Xu via cfe-commits]

ChuanqiXu9 wrote:

> I think going down this path is going to cause real issues for users. There's a reason this behavior was added in the first place for Clang modules, as Clang makes assumptions about the shape of the AST which can lead to crashes in some cases. For example, in real world code that uses the stdlib you are incredibly unlikely to actually be able to mix code that uses different language versions.
> 
> We've gone through a lot of the LANGOPTs already to try and see if we can demote the ones we see to BENIGN, and lots of them end up having macros or AST differences that make this not possible. There are some that could be changed to work by delaying their effect until later, but that hasn't been done yet. For instance we've even had issues with allowing differences in optimization level because it sets the `__OPTIMIZE__` predefined macro which caused a real bug when we ignored it. At large scale these differences creep in, and we have no way to know when they matter.
> 
> There's also a problem with the global module fragment and header units which make these kinds of issues even worse, you really can't get the preprocessor state wrong or you get real ODR issues.
> 
> We've discussed this a bunch in the Tooling study group in the committee, and the general consensus is that build systems need to arrange to build BMIs with the correct settings, and it's entirely expected that the BMI you use for a named module may not be the same one that was built when actually building the .o for that TU. Really we would have to remove the preprocessor from C++ to be able to get away from this.

For SG15 related things, I discussed them in https://github.com/llvm/llvm-project/pull/115416. In short, they're similar but different stories. Since we can't model `-D` well in the compiler side after all.

> There's a reason this behavior was added in the first place for Clang modules, as Clang makes assumptions about the shape of the AST which can lead to crashes in some cases.

If there are crashes, I think we'd better to fix these crahes.

> There's also a problem with the global module fragment and header units which make these kinds of issues even worse, you really can't get the preprocessor state wrong or you get real ODR issues.

I still think this is related but another topic. We are already in this case now. We're already facing the potential ODR violations caused by preprocessors no matter we enabled modules or not. This is the same before and after this patch.



https://github.com/llvm/llvm-project/pull/117840