================
@@ -3384,9 +3384,30 @@ ASTContext::getASTRecordLayout(const RecordDecl *D)
const {
// not a complete definition (which is what isCompleteDefinition() tests)
// until we *finish* parsing the definition.
D = D->getDefinition();
- assert(D && "Cannot get layout of forward declarations!");
- assert(!D->isInvalidDecl() && "Cannot get layout of invalid decl!");
- assert(D->isCompleteDefinition() && "Cannot layout type before complete!");
+
+ // Handle invalid declarations gracefully during error recovery
+ // This can happen when there are template specialization errors
+ if (!D || D->isInvalidDecl() || !D->isCompleteDefinition()) {
+ // Check if we already have a cached layout
+ const ASTRecordLayout *Entry = ASTRecordLayouts[D];
+ if (Entry)
+ return *Entry;
+
+ // Create a minimal safe layout for error recovery
----------------
AaronBallman wrote:
This kind of error recovery seems like it may end up causing some really weird
follow-on diagnostics. e.g., imagine an erroneous declaration of a struct type
which is then used in a `sizeof` in `static_assert`, that kind of thing.
Are we sure this is the best form of recovery? Would it make more sense to
update the interface so that it can report failures and callers have to be
prepared to fail gracefully?
I'm not exactly opposed to the current direction, mostly just thinking through
the implications and troubles it may cause.
CC @vgvassilev for additional opinions because I expect clang-repl can hit
these kinds of failures
https://github.com/llvm/llvm-project/pull/208153
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
