[clang][Modules] Fix the Size of RecordDecl's BitCodeAbbrevOp

[qiongsiwu]

https://github.com/llvm/llvm-project/pull/102040/files#diff-125f472e690aa3d973bc42aa3c5d580226c5c47661551aca2889f960681aa64dR2477 added 1 bit to RecordDecl's serialization format, but did not increment its abbreviation size.

This can lead to rare cases where a record may overflow if the RecordDecl's getArgPassingRestrictions() returns something bigger than 1 (see here).

rdar://143763558

[llvmbot]

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-modules

Author: Qiongsi Wu (qiongsiwu)

Changes

https://github.com/llvm/llvm-project/pull/102040/files#diff-125f472e690aa3d973bc42aa3c5d580226c5c47661551aca2889f960681aa64dR2477 added 1 bit to RecordDecl's serialization format, but did not increment its abbreviation size.

This can lead to rare cases where a record may overflow if a RecordDecl's getArgPassingRestrictions() returns something bigger than 1 (see here).

---

Full diff: https://github.com/llvm/llvm-project/pull/133500.diff

1 Files Affected:

• (modified) clang/lib/Serialization/ASTWriterDecl.cpp (+1-1)

diff --git a/clang/lib/Serialization/ASTWriterDecl.cpp b/clang/lib/Serialization/ASTWriterDecl.cpp
index a14b8cf201bba..f377c145a4204 100644
--- a/clang/lib/Serialization/ASTWriterDecl.cpp
+++ b/clang/lib/Serialization/ASTWriterDecl.cpp
@@ -2579,7 +2579,7 @@ void ASTWriter::WriteDeclAbbrevs() {
   // RecordDecl
   Abv->Add(BitCodeAbbrevOp(
       BitCodeAbbrevOp::Fixed,
-      13)); // Packed Record Decl Bits: FlexibleArrayMember,
+      14)); // Packed Record Decl Bits: FlexibleArrayMember,
             // AnonymousStructUnion, hasObjectMember, hasVolatileMember,
             // isNonTrivialToPrimitiveDefaultInitialize,
             // isNonTrivialToPrimitiveCopy, isNonTrivialToPrimitiveDestroy,

[qiongsiwu]

Note to reviewers:

A test case is added by swiftlang#10371. This is difficult to test in the community llvm code base because the failure was discovered when building structs with __ptrauth, which is not available here. I tried a few things to simulate the situation but found it difficult. I am all ears if there are better ways to test this.

More generally, should we hardcode the size in BitCodeAbbrevOp at all? It feels that some mistakes are bound to happen when things go out of sync. My intuition is that it might be a major surgery to refactor this code but I have not looked into it in detail.

[higher-performance]

Thank you for spotting & fixing this! Approving, but I'm also quite unfamiliar with these so please wait for another approval.

[ChuanqiXu9]

LGTM. Thanks.