rsmith added a comment. Generally I think we should be moving towards finer-grained "invalid" / "contains errors" bits, so that we can preserve as much of the AST as possible and produce accurate diagnostics for independent errors wherever possible. To that end, I think generally the "invalid" bit on a declaration should concern *only* the "declaration" part of that declaration (how it's seen from other contexts that don't "look too closely"). So in particular:
- The initializer of a variable should play no part in its "invalid" bit. If the initializer expression is marked as "contains errors", then things that care about the initializer (in particular, constant evaluation and any diagnostics that look into the initializer) may need to bail out, but we should be able to form a `DeclRefExpr` referring to that variable -- even if (say) the variable is `constexpr`. Exception: if the variable has a deduced type and the type can't be deduced due to an invalid initializer, then the declaration should be marked invalid. - The body of a function should play no part in its "invalid" bit. (This came up in a different code review recently.) We shouldn't build a `DeclRefExpr` to a declaration whose "invalid" bit is set, because (for example) we don't necessarily know what type that expression has. Building a `RecoveryExpr` in that case seems reasonable. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76831/new/ https://reviews.llvm.org/D76831 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
