[clang] [C++20] [Modules] Introduce -fskip-odr-check-in-gmf (PR #79959)

[Chuanqi Xu via cfe-commits]

================
@@ -457,6 +457,28 @@ Note that **currently** the compiler doesn't consider inconsistent macro definit
 Currently Clang would accept the above example. But it may produce surprising results if the
 debugging code depends on consistent use of ``NDEBUG`` also in other translation units.
 
+Definitions consistency
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The C++ language defines that same declarations in different translation units should have
+the same definition, as known as ODR (One Definition Rule). Prior to modules, the translation
+units don't dependent on each other and the compiler itself don't and can't perform a strong
+ODR violation check. Sometimes it is the linker does some jobs related to ODR, where the
+higher level semantics are missing. With the introduction of modules, now the compiler have
+the chance to perform ODR violations with language semantics across translation units.
+
+However, in the practice we found the existing ODR checking mechanism may be too aggressive.
+In the many issue reports about ODR violation diagnostics, most of them are false positive
+ODR violations and the true positive ODR violations are rarely reported. Also MSVC don't
+perform ODR check for declarations in the global module fragment.
----------------
ChuanqiXu9 wrote:

>> Great insight. I feel this is meaningful. Maybe we need to reach out WG21 to confirm this. Can you access the mailing list of WG21?

> I am not a member yet, but I know a few people in there.

Do you need me to send this? I feel this is the deepest problem in the discussion.

>  clang bug I am currently working on

Is there an issue report?

> So I feel we are taking a drastic step here based on potentially incorrect evidence.

To me, the issue is `the straw that broke the camel's back`. I've seen too many issue reports saying and complaining the false positive ODR violations publicly and privately. It is a long battle.

> If we can confirm what I am saying, then don't you agree we would be losing the whole casus belli against the GMF ODR checker, and we could go back to square one, revert the whole thing, and take a better look at this?

If we can have a stable and correct ODR checker, we have no reasons to not enable it.

> Even if that is not the only issue, my perception is that other supposed ODR violations could be simple issues like this.

My experience is "yes, a lot of false positive ODR violations can be fixed by simple patch". The only problem is that there is **too many**.

> See above. Would you mind waiting a little for my patch, for us to double check we are taking this step with solid footing?

Or let's take a step back. How about always enabling the ODR checker for decls in the GMF but offering a driver flag "-fskip-odr-check-in-gmf"? Then the users can get better experience and offer more precise issue report. Also we don't need to be in the panic of losing standard conformance.

> On the other hand, this does not seem to be a regression, since the whole C++20 modules thing is just coming up and we are talking about a new feature and new users.

I think it is saying the users converting a repo from headers to modules.


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