Clang crash with -Wunsafe-buffer-usage on assertion failure: const ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const RecordDecl *) const: Assertion `D && "Cannot get layout of forward declarations!"' failed.

[ZequanWu]

Trunk clang crashes with -Wunsafe-buffer-usage: https://godbolt.org/z/Pjj413W68 and https://godbolt.org/z/j4hnY3eEz.

#91991 (reverted) introduced the same crash with -Wunsafe-buffer-usage: https://godbolt.org/z/vcv8d6sYr, which is likely due to the same underlying issue.

[danakj]

To help make things clear, #91991 did not introduce the crash, it exposed the crash in Chromium code because it ran the analysis machinery on code inside field initializers. The crash happens outside of field initializers too, but the problematic code is only in a field initializer in Chromuim.

Once the underlying issue is fixed, the revert of #91991 can be reverted to reland it, as there's no related bug in that PR afaik.

[danakj]

@haoNoQ I am no longer working in Chromium so I won't have a lot of time to follow up here. And the bug appears to be in the handling of casts in AnalysisBasedWarnings at

llvm-project/clang/lib/Sema/AnalysisBasedWarnings.cpp

Lines 2271 to 2277 in 7d20ea9

	} else if (const auto *ECE = dyn_cast<ExplicitCastExpr>(Operation)) {
	QualType destType = ECE->getType();
	if (!isa<PointerType>(destType))
	return;
	const uint64_t dSize =
	Ctx.getTypeSize(destType.getTypePtr()->getPointeeType());

Could you handle triaging this?

[ZequanWu]

A further reduced repro for https://godbolt.org/z/vcv8d6sYr: https://godbolt.org/z/1vn6adWhc

[ziqingluo-90]

@danakj I will work on it.

[ziqingluo-90]

https://godbolt.org/z/1vn6adWhc

Hi @ZequanWu, I'd prefer to keep the assumption that std::array::data()/std::span::data() always return a pointer. In your example, it returns an int. Is it coming from any real code where std::array::data() returns a non-pointer?

[ZequanWu]

https://godbolt.org/z/1vn6adWhc

Hi @ZequanWu, I'd prefer to keep the assumption that std::array::data()/std::span::data() always return a pointer. In your example, it returns an int. Is it coming from any real code where std::array::data() returns a non-pointer?

I think it's just reduced by creduce. Changing data() to return a pointer also cause crash: https://godbolt.org/z/coT53Kh5j

[ziqingluo-90]

https://godbolt.org/z/1vn6adWhc

Hi @ZequanWu, I'd prefer to keep the assumption that std::array::data()/std::span::data() always return a pointer. In your example, it returns an int. Is it coming from any real code where std::array::data() returns a non-pointer?

I think it's just reduced by creduce. Changing data() to return a pointer also cause crash: https://godbolt.org/z/coT53Kh5j

Yup, it is not the cause of the crash. For the crash I have a fix here: #116433. It is caused by trying to get the type size from an incomplete type.

What I was talking about above is that your original example will hit an assertion violation after the fix. Because we assume std::array::data() always return pointers. We assume these hardened(-able) containers/views are standard otherwise many other places in the code need change.