[clang-tidy] bugprone-sizeof-expression crashes for templated types on clang 21.1.1

[sfc-gh-mheimel]

Summary
clang-tidy crashes (often, but not always) when the bugprone-sizeof-expression check analyzes a sizeof applied to a templated array variable inside a function template. The crash appears in ASTContext::getTypeInfoImpl (sometimes preceded by TypeOfExprType::desugar()), suggesting recursion while computing type info for a dependent ConstantArrayType.

Minimal repro

// playground.cpp
template <typename T>
void test() {
  T in[10];
  for (int j = 0; j < sizeof(in); ++j) {}
}

Command

clang-tidy --checks=-*,bugprone-sizeof-expression playground.cpp

Observed behavior

• Segfaults in ~8/10 runs (non-deterministic); sometimes succeeds.
• Two common stacks seen (trimmed tops):

Crash 1:

#0  clang::TypeOfExprType::desugar() const
#1  clang::ASTContext::getTypeInfoImpl(clang::Type const*) const
#2  clang::ASTContext::getTypeInfoImpl(clang::Type const*) const
    ... (repeats many times) ...
Segmentation fault (core dumped)

Crash 2:

#0  clang::ASTContext::getTypeInfoImpl(clang::Type const*) const
#1  clang::ASTContext::getTypeInfoInChars(clang::QualType) const
#2  clang::ASTContext::getTypeSizeInChars(clang::QualType) const
#3  clang::tidy::bugprone::SizeofExpressionCheck::check(...)
#4  clang::ast_matchers::internal::MatchASTVisitor::MatchVisitor::visitMatch(...)
Segmentation fault (core dumped)

Matcher dump right before the crash (from clang-tidy output):

ASTMatcher: Processing 'bugprone-sizeof-expression' against:
  ForStmt : <playground.cpp:4:3, col:40>
--- Bound Nodes Begin ---
  loop-expr       - { ForStmt : <playground.cpp:4:3, col:40> }
  sizeof-arg-type - { ConstantArrayType : T[10] }
  sizeof-expr     - { UnaryExprOrTypeTraitExpr : <playground.cpp:4:23, col:30> }
--- Bound Nodes End ---

Notes / patterns

• The crash only manifests when the array element type is a template (T in[10];).
• The matcher dump shows sizeof-arg-type as ConstantArrayType : T[10].
• Looks like computing size for a dependent array type can trigger recursion in getTypeInfoImpl().
• Disabling bugprone-sizeof-expression avoids the crash.
• Replacing the templated type with a regular one (e.g., int in[10];) does not crash in my testing.
• Wrapping the code in // NOLINTBEGIN(bugprone-sizeof-expression) ... // NOLINTEND(bugprone-sizeof-expression) does not avoid the crash.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Max Heimel (sfc-gh-mheimel)

**Summary** `clang-tidy` crashes (often, but not always) when the **`bugprone-sizeof-expression`** check analyzes a `sizeof` applied to a templated array variable inside a function template. The crash appears in `ASTContext::getTypeInfoImpl` (sometimes preceded by `TypeOfExprType::desugar()`), suggesting recursion while computing type info for a dependent `ConstantArrayType`.

Minimal repro

// playground.cpp
template <typename T>
void test() {
  T in[10];
  for (int j = 0; j < sizeof in; ++j) {}
}

Command
(also reproduces with sizeof(in))

clang-tidy --checks=-*,bugprone-sizeof-expression playground.cpp

Observed behavior

• Segfaults in ~8/10 runs (non-deterministic); sometimes succeeds.
• Two common stacks seen (trimmed tops):

Crash 1:

#<!-- -->0  clang::TypeOfExprType::desugar() const
#<!-- -->1  clang::ASTContext::getTypeInfoImpl(clang::Type const*) const
#<!-- -->2  clang::ASTContext::getTypeInfoImpl(clang::Type const*) const
    ... (repeats many times) ...
Segmentation fault (core dumped)

Crash 2:

#<!-- -->0  clang::ASTContext::getTypeInfoImpl(clang::Type const*) const
#<!-- -->1  clang::ASTContext::getTypeInfoInChars(clang::QualType) const
#<!-- -->2  clang::ASTContext::getTypeSizeInChars(clang::QualType) const
#<!-- -->3  clang::tidy::bugprone::SizeofExpressionCheck::check(...)
#<!-- -->4  clang::ast_matchers::internal::MatchASTVisitor::MatchVisitor::visitMatch(...)
Segmentation fault (core dumped)

Matcher dump right before the crash (from clang-tidy output):

ASTMatcher: Processing 'bugprone-sizeof-expression' against:
  ForStmt : <playground.cpp:4:3, col:40>
--- Bound Nodes Begin ---
  loop-expr       - { ForStmt : <playground.cpp:4:3, col:40> }
  sizeof-arg-type - { ConstantArrayType : T[10] }
  sizeof-expr     - { UnaryExprOrTypeTraitExpr : <playground.cpp:4:23, col:30> }
--- Bound Nodes End ---

Notes / patterns

• The crash only manifests when the array element type is a template (T in[10];).
• The matcher dump shows sizeof-arg-type as ConstantArrayType : T[10].
• Looks like computing size for a dependent array type can trigger recursion in getTypeInfoImpl().
• Disabling bugprone-sizeof-expression avoids the crash.
• Replacing the templated type with a regular one (e.g., int in[10];) does not crash in my testing.
• Wrapping the code in // NOLINTBEGIN(bugprone-sizeof-expression) ... // NOLINTEND(bugprone-sizeof-expression) does not avoid the crash.

[vbvictor]

Wrapping the code in // NOLINTBEGIN(bugprone-sizeof-expression) ... // NOLINTEND(bugprone-sizeof-expression) does not avoid the crash.

This is generally expected because //NOLINT tokens are processed after all warning are gathered (and the check crushes in the process of it).

[localspook]

We seem to be trying to compute sizeof(T), which doesn't make sense because T is dependent:

llvm-project/clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp

Lines 378 to 381 in 9490d58

	if (const auto *Type = dyn_cast<ArrayType>(SizeofArgTy)) {
	// check if the array element size is larger than one. If true,
	// the size of the array is higher than the number of elements
	CharUnits SSize = Ctx.getTypeSizeInChars(Type->getElementType());

We actually have a function that handles this case by returning 0:

llvm-project/clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp

Lines 53 to 58 in 9490d58

	CharUnits getSizeOfType(const ASTContext &Ctx, const Type *Ty) {
	if (!Ty || Ty->isIncompleteType() || Ty->isDependentType() ||
	isa<DependentSizedArrayType>(Ty) || !Ty->isConstantSizeType())
	return CharUnits::Zero();
	return Ctx.getTypeSizeInChars(Ty);
	}

So maybe we should be using that instead?

[vbvictor]

So maybe we should be using that instead?

Yes we should