================
@@ -1098,12 +1098,39 @@ static TypeSourceInfo
*getTypeSourceInfoForStdAlignValT(Sema &S,
return S.Context.getTrivialTypeSourceInfo(StdAlignValDecl);
}
+// When searching for custom allocators on the PromiseType we want to
+// warn that we will ignore type aware allocators.
+static bool DiagnoseTypeAwareAllocators(Sema &S, SourceLocation Loc,
+ unsigned DiagnosticID,
+ DeclarationName Name,
+ QualType PromiseType) {
+ assert(PromiseType->isRecordType());
+
+ LookupResult R(S, Name, Loc, Sema::LookupOrdinaryName);
+ S.LookupQualifiedName(R, PromiseType->getAsCXXRecordDecl());
+ bool HaveIssuedWarning = false;
+ for (auto Decl : R) {
+ if (!Decl->getAsFunction()->isTypeAwareOperatorNewOrDelete())
+ continue;
+ if (!HaveIssuedWarning) {
+ S.Diag(Loc, DiagnosticID) << Name;
+ HaveIssuedWarning = true;
+ }
+ S.Diag(Decl->getLocation(), diag::note_type_aware_operator_declared)
+ << /* isTypeAware */ 1 << Decl << Decl->getDeclContext();
----------------
ojhunt wrote:
I believe we've established that getDeclContext is correct, and that friend,
etc decls can't be used to pull new/delete around into unexpected scopes.
(Strictly, consider a hypothetical where you could pull new/delete in from
other scopes, e.g.
```cpp
class SomeClass {
operator new = yoinked from some other context;
operator delete = yoinked from a different context;
}
```
We would not want to be reporting the lexical context (`SomeClass`) because the
error is new and delete coming from different decl contexts, e.g. the fact that
new and delete decls in SomeClass have the same lexical context is not
relevant, the actual functions are from different contexts that would be a
mismatch.
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
