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