================ @@ -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:
I think there are many kinds of issues here and the text might not be conveying the right idea. 1) There are some clang bugs where wrong semantic analysis occurs when building AST from pcm, where otherwise parsing from source produces correct results. This is not a problem in ODR checking per se, but it can manifest itself as that, and this ends up being helpful. 2) Bugs in the ODR checker itself, where two identical definitions, per the standard, are mistaken as different, or the opposite. 3) ODR violations in user code, which can some times be mostly harmless, and some times not. I read this paragraph as talking about 3 in particular, and giving the idea that the ODR, as specified, ends up barfing at too many harmless violations, and we are finding that it's more trouble than it's worth as we enforce it in more situations. Regarding MSVC, I don't think we normally would relax standards conformance so broadly in order to be consistent with another compiler. For example, see how we handle compatibility with MSVC regarding delayed template parsing. 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
