================
@@ -1829,10 +1829,18 @@ class DeclContext {
// refers to an enclosing template for hte purposes of [temp.friend]p9.
LLVM_PREFERRED_TYPE(bool)
uint64_t FriendConstraintRefersToEnclosingTemplate : 1;
+
+ // Indicates this function is type aware operator new or delete
+ LLVM_PREFERRED_TYPE(bool)
+ uint64_t IsDestroyingOperatorDelete : 1;
+
+ // Indicates this function is type aware operator new or delete
+ LLVM_PREFERRED_TYPE(bool)
+ uint64_t IsTypeAwareOperatorNewOrDelete : 1;
----------------
ojhunt wrote:
I'm not convinced that the concern about the cost of these bits is really
justified, however for the time being I've switched to a pair of `DenseSet`s on
ASTContext which maintains the general design win of being able to do correct
(and fast[er]) checks on the operator kind through the FunctionDecl without
access to Sema. In the short term this also gives us the ability to track the
existence of any type aware new or delete operators so we can short circuit
type aware allocator lookup until we restructure operator lookup to be less
like the spec language and much more efficient in general.
The DenseSet caches in ASTContext technically help performance, but the primary
reason for this model is to help the overall design: it allows us to only have
a single implementation of "is this type aware" and "is this destroying delete"
semantics (that lives in Sema) rather than having the very subtle difference in
semantics we get from Sema (that does fully correct type checks) and what are
essentially just the type name check we were using before which technically
makes it possible to have diverging definitions, though *in principle* the
rules in Sema would mean that if there was divergence the sema checks would
have failed and codegen would not be reached.
https://github.com/llvm/llvm-project/pull/113510
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
