aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/DXContainer.cpp
diff options
context:
space:
mode:
authorChuanqi Xu <yedeng.yd@linux.alibaba.com>2024-11-27 10:53:03 +0800
committerGitHub <noreply@github.com>2024-11-27 10:53:03 +0800
commit74449ab86b8bc8d7388ede0cc7fc3a679da0c567 (patch)
treec9413c135d871938c74133b578acbc6c046bf6f6 /llvm/lib/Object/DXContainer.cpp
parent90a776fbdb35ef6ac6f28a19937e88abd2e4611b (diff)
downloadllvm-74449ab86b8bc8d7388ede0cc7fc3a679da0c567.zip
llvm-74449ab86b8bc8d7388ede0cc7fc3a679da0c567.tar.gz
llvm-74449ab86b8bc8d7388ede0cc7fc3a679da0c567.tar.bz2
[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=`.
Diffstat (limited to 'llvm/lib/Object/DXContainer.cpp')
0 files changed, 0 insertions, 0 deletions