[llvm-branch-commits] [clang] release/22.x: [C++20] [Modules] Add VisiblePromoted module ownership kind (#189903) (PR #192885)

[Aaron Ballman via llvm-branch-commits]

================
@@ -1575,7 +1575,7 @@ void Sema::makeMergedDefinitionVisible(NamedDecl *ND) {
   if (auto *ED = dyn_cast<EnumDecl>(ND);
       ED && ED->isFromGlobalModule() && !ED->isScoped()) {
     for (auto *ECD : ED->enumerators()) {
-      ECD->setVisibleDespiteOwningModule();
+      ECD->setVisiblePromoted();
----------------
AaronBallman wrote:

I have never been fully happy with the version number situation in serialization because it's awkward to know who should bump that and when. The rule of thumb I've followed for years is that one of the first patches in a new release cycle which materially changes serialization is picked to change the version number. So the versions are not super helpful for intra-release development work, but are helpful for releases to users. But I don't like this because 1) it's easy to forget to update at all, 2) downstreams don't release based off upstream release cycles so it's awkward for them, 3) using ToT Clang with serialization is frustrating unless you have very good hygiene with your build artifacts.

That said, I'm strongly opposed to the commit hash being used as a long-term solution. That's terrible QoI particularly around use with dot releases. We go to such great lengths to make sure that each dot release matches the ABI of the last one because we want the patch releases to be drop-in replacements for each other. It's fine for serialization to change between Clang 21 and Clang 22 (obviously!), it's probably even fine for serialization to change between Clang 22.1 and Clang 22.2. But IMO serialization should not change between Clang 22.1.1 and Clang 22.1.2.

https://github.com/llvm/llvm-project/pull/192885