================ @@ -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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
