[Clang] Ignore invalid base classes

[shashforge]

When building a RecordDecl, ignore invalid base classes. This solves crashes later on and leads to better recovery.

Fixes #147186

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[llvmbot]

@llvm/pr-subscribers-clang

Author: Shashi Shankar (shashi1687)

Changes

Summary

Briefly what this PR does, in one or two sentences.
> Filters out invalid (null) base-specifiers in ActOnBaseSpecifiers(), preventing ICEs on incomplete or non-class bases.

Motivation

Why this change is needed.
> When you inherit from a forward‐declared class or non-class type, Sema used to emit an error and still hand the bad pointer to later code, causing an internal compiler error. We now drop those invalid entries immediately.

Root Cause Analysis

A very short bulleted “root cause.”

• ActOnBaseSpecifier returns nullptr for invalid bases.
• ActOnBaseSpecifiers passed all pointers (including null) to AttachBaseSpecifiers.
• Later layout or special‐member lookup on null caused the ICE.

Changes in this PR

List the key files and rough diff summary.

• clang/lib/Sema/SemaDeclCXX.cpp
  • In ActOnBaseSpecifiers(), gather Bases into a SmallVector, skipping null entries.
• clang/test/SemaCXX/invalid-base-inheritance.cpp
  • New regression test checking for the proper diagnostics and that no ICE occurs.

Test Plan

How you verified the change.

1. Local build/test

   mkdir build && cd build
   cmake -G Ninja ../llvm \
     -DLLVM_ENABLE_PROJECTS="clang" \
     -DCMAKE_BUILD_TYPE=Release
   ninja clang
   ninja check-clang
   
   

---

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

2 Files Affected:

• (modified) clang/lib/Sema/SemaDeclCXX.cpp (+16-1)
• (added) clang/test/SemaCXX/invalid-base-inheritance.cpp (+17)

diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index f0247f865ba40..231610241d8ee 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -3031,8 +3031,23 @@ void Sema::ActOnBaseSpecifiers(Decl *ClassDecl,
   if (!ClassDecl || Bases.empty())
     return;
 
+  // --- drop any bases already diagnosed invalid ---
+  SmallVector<CXXBaseSpecifier *, 4> ValidBases;
+  ValidBases.reserve(Bases.size());
+  for (auto *BS : Bases)
+       if (BS)
+          ValidBases.push_back(BS);
+  if (ValidBases.empty())
+       return;
+
+  if (ValidBases.empty())
+    return; // nothing valid to attach
+
   AdjustDeclIfTemplate(ClassDecl);
-  AttachBaseSpecifiers(cast<CXXRecordDecl>(ClassDecl), Bases);
+  // Attach only the valid bases so downstream never ICEs
+  AttachBaseSpecifiers(cast<CXXRecordDecl>(ClassDecl),
+                       llvm::MutableArrayRef<CXXBaseSpecifier *>(
+                       ValidBases.data(), ValidBases.size()));
 }
 
 bool Sema::IsDerivedFrom(SourceLocation Loc, CXXRecordDecl *Derived,
diff --git a/clang/test/SemaCXX/invalid-base-inheritance.cpp b/clang/test/SemaCXX/invalid-base-inheritance.cpp
new file mode 100644
index 0000000000000..e37b77bcd3fea
--- /dev/null
+++ b/clang/test/SemaCXX/invalid-base-inheritance.cpp
@@ -0,0 +1,17 @@
+// Tests that invalid base-specifiers no longer crash the compiler.
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+class X;              // forward declaration
+
+class A : X {         // incomplete base → error, but no ICE
+    // expected-error@-1 {{base class has incomplete type}}
+};
+
+class Y : int {       // base not a class → error, but no ICE
+  // expected-error@-1 {{expected class name}}
+};
+
+class Z : X*, virtual int { // mixed invalid specifiers
+    // expected-error@-2 {{base class has incomplete type}}
+    // expected-error@-1 {{expected class name}}
+};

[cor3ntin]

Thanks for working on this

Did you try to use !isUsable instead of IsInvalid in
ParseBaseSpecifier ? I think that might be a simpler fix.

---

This change needs a release note.
Please add an entry to clang/docs/ReleaseNotes.rst in the section the most adapted to the change, and referencing any Github issue this change fixes. Thanks!

[shashforge]

Thanks for working on this

Did you try to use !isUsable instead of IsInvalid in ParseBaseSpecifier ? I think that might be a simpler fix.

This change needs a release note. Please add an entry to clang/docs/ReleaseNotes.rst in the section the most adapted to the change, and referencing any Github issue this change fixes. Thanks!

Thank you so much for the suggestion and for taking the time to review this! 🙏 I’ve switched over to using !BaseTy->isUsableType() in ParseBaseSpecifier, dropped the old isInvalid checks, and added the following one-line entry under “Bug Fixes” in clang/docs/ReleaseNotes.rst:

* Fixed a crash when parsing an unusable type as a base specifier. (#147213)

I’ve also updated the commit message to:

ParseDeclCXX: reject unusable base classes via isUsableType

In Parser::ParseBaseSpecifier, use !BaseTy->isUsableType() to early-reject
any class/struct/union that isn’t instantiable as a base. Add a release note.
Fixes #147213.

Could you please take another look and let me know if anything else needs tweaking? Thanks again for your guidance!

[cor3ntin]

LGTM

[github-actions]

@shashi1687 Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!