================
@@ -1618,8 +1618,26 @@ void ASTContext::setRelocationInfoForCXXRecord(
RelocatableClasses.insert({D, Info});
}
+// In future we may want to distinguish the presence or absence of address
+// discrimination, from the inability to determine the presence. For now we
rely
+// on all source facing interfaces (type trait queries, etc) diagnosing and
+// reporting an error before reaching these paths.
+static bool canDeterminePointerAuthContent(QualType Type) {
+ if (Type->isIncompleteType() || Type->isDependentType())
+ return false;
+ const TagDecl *Decl = Type->getAsTagDecl();
+ return !Decl || !Decl->getDefinition()->isInvalidDecl();
----------------
ojhunt wrote:
I was worried about making more widespread changes, but I'll give that a shot -
certainly it seems reasonable to consider invalid as being incomplete.
I had a comment for Corentin asking if there's an existing function that
basically answers the "is this a complete, valid, and fully instantiated type"
(rather than these local helpers), but I'm not sure if such a query has any
value beyond this specific case. Certainly if we were to use some bits in the
type/decl and evaluate this logic eagerly in future this logic disappears and
the query would become unnecessary so if there's no other need for such a
general there would be no reason to add it globally.
Anyway, that last paragraph is independent of isIncomplete also testing for
isInvalid. I have a suspicion that we may get some issues with diagnostics - at
least the diagnostic messages themselves changing, I can't imagine it impacting
actual correctness, but lets find out :D
https://github.com/llvm/llvm-project/pull/164528
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
