[all-commits] [llvm/llvm-project] 74449a: [Serialization] Downgrade inconsistent flags from ...

[Chuanqi Xu via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 74449ab86b8bc8d7388ede0cc7fc3a679da0c567
      https://github.com/llvm/llvm-project/commit/74449ab86b8bc8d7388ede0cc7fc3a679da0c567
  Author: Chuanqi Xu <yedeng.yd at linux.alibaba.com>
  Date:   2024-11-27 (Wed, 27 Nov 2024)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/Basic/DiagnosticGroups.td
    M clang/include/clang/Basic/DiagnosticSerializationKinds.td
    M clang/lib/Serialization/ASTReader.cpp
    M clang/test/Modules/explicit-build-missing-files.cpp
    M clang/test/Modules/load_failure.c
    M clang/test/Modules/mismatch-diagnostics.cpp
    M clang/test/Modules/module-feature.m
    M clang/test/Modules/pr62359.cppm
    M clang/test/Modules/prebuilt-implicit-modules.m
    M clang/test/PCH/arc.m
    M clang/test/PCH/no-validate-pch.cl
    M clang/test/PCH/pch-dir.c

  Log Message:
  -----------
  [Serialization] Downgrade inconsistent flags from erros to warnings (#115416)

There were many many "voices" about the too strict flags checking in
modules. Although they rarely challenge this, maybe due to they respect
to the compiler implementation details. But from my point of view, there
are cases it is "fine" to have different flags. Especially we're too
conservative to mark almost language options in
`clang/include/clang/Basic/LangOptions.def` as incompatible options (see
the comments in the front of the file).

In my understanding, this should come from PCH initially since it is
natural to ask your headers to be compiled with the same flags with your
TU. And then, when Apple and Google goes to implement clang module, they
don't challenge it too since they have a closed world where they have a
strong control over the ecosystem so that they can make it consistent.

Yes, consistency is great and ODR violation are awful. But this is the
world we're living today. This is the C++'s ecosystem in the open ended
world. Image a situation that we're using a third party module and we
add a new option to our library, then the build bails out! THIS IS SUPER
ANNOYING. And makes it non practical to make a modular C++ ecosystem.

(
This was discussed many times in SG15. And the consensus is, the build
systems should generate different BMI based on different flags. But this
manner can't avoid ODR violation completely and it would add the times
of module files that need to be built, which may kill the benefit of
faster compilation of modules.

However, I think the build systems may need to do the similar things in
the end of the day. Considering libc++'s hardening mechanism
(https://libcxx.llvm.org/Hardening.html). So the conclusion of the
paragraph is, although this seems related to build systems, I think they
are actually unrelated story.
)

I think we should give our users a chance to disable such checks. It is
theoretically unsafe. But we've done our job to tell the users that it
**MAY** be bad. Then I feel it is C++-ish to give users more freedom
even if they may shoot their foot.

This shouldn't change any thing. Users who want previous behavior can
get it easily by `-Werror=`.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications