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

[Matheus Izvekov 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.
----------------
mizvekov wrote:

>For 2, I thought the term false positive implies 2. But maybe it is not impressive. So I tried to rewrite this paragraph to make it more explicit.

That is surprising to me, because the issue you linked in the original commit, #78850, seems to be a case of 3) to me, mostly harmless but nonetheless an ODR violation.

This is not just about the semantics of the resulting program itself, think about debug info: There will be two definitions of `fun`, with slightly different debug info, because they refer to different declarations for T, even if they resolve to the same type.

Even if the standard wording talks about the definitions consisting of the same series of tokens, this to me is a case of rule-as-written vs rule-as-intended. Ie the tokens not only have to be same textually, but they need to refer to the same entity.

> For 1, I don't understand why it is relevant here. I know what you're saying, but I just feel it is not related here. We're talking about ODR checker, right?

See above, but I am also currently internally tracking two separate bugs which are a case of 1), and the ODR checker was just an innocent witness.

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