================
@@ -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:

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

Sure, we can move that part of the discussion over there.

> 
> Is there an issue report?
> 

Not on the llvm issue tracker yet, I am working on getting issue + patch up 
soon.

> 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.
> 

How are we tracking these issues, is there a special tag for them? We could 
take a better look, attack this systematically.

> 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**. Or this may be 
> the reason I feel the current ODR checker is not stable enough.

Right, but reducing these issues takes a lot of effort. On the other hand, it's 
possible they all reduce to a few simple cases.
This is my perception so far, working on converting a medium size code base.

> 
> 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.

Yeah, one concern is losing the bug reports.
While we do offer driver flags to facilitate testing experimental features, 
which I think C++20 modules falls under, 
this may be too technical detail to expose to users.

So I will go ahead and approve this, even though I feel this might have been 
too hasty, as long as we are running the clang test suite as before, then we 
can make progress in fixing all the problems and circle back to always enabling 
the checker.

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

Right, but that's not a regression.


https://github.com/llvm/llvm-project/pull/79959
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to