[clang] [win][clang] Align scalar deleting destructors with MSABI (PR #139566)

[Tom Honermann via cfe-commits]

================
@@ -2886,6 +2887,16 @@ class CXXDestructorDecl : public CXXMethodDecl {
     return getCanonicalDecl()->OperatorDelete;
   }
 
+  const FunctionDecl *getOperatorGlobalDelete() const {
+    return getCanonicalDecl()->OperatorGlobalDelete;
+  }
+
+  void setOperatorGlobalDelete(FunctionDecl *OD) {
----------------
tahonermann wrote:

Hmm, it seems there is some inconsistency in the implementation vs what is in the paper.

[P2719R5](https://wg21.link/p2719r5) has a publication date of 2025-05-12, [P2719R4](https://wg21.link/p2719r4) has a publication date of 2025-02-10, and the [initial implementation](https://github.com/llvm/llvm-project/commit/1cd59264aa2fb4b0ba70ff03c1298b1b5c21271e) in Clang landed on April 10th. It looks like the current implementation likely implements P2719R4; I don't see a later commit that raises it to P2719R5. No revision of P2719 has been approved for a C++ standard yet and there are some obvious wording issues in P2719R5, so we're in uncertain territory here.

One of the main differences between P2719R4 and P2719R5 is that the latter treats type aware allocation and deallocation operators declared in the global namespace as *replaceable global allocation functions*. That explains why `isReplaceableGlobalAllocationFunction()` returns `false` for the type aware operators.

Regardless, what we're interested in here are *usual deallocation functions*. Both P2719R4 and P2719R5 specify that type aware deallocation functions are *usual deallocation functions*, so I agree with your assessment that we should include the type aware deallocation functions.

`isNonPlacementDeallocationFunction()` really looks like the right function to me. Though not a trivial change, I think it would be reasonable to relax `Sema::isUsualDeallocationFunction()` to take a `FunctionDecl` and to effectively return `isNonPlacementDeallocationFunction()` for a call for a non-`CXXMethodDecl` decl. That seems out of scope for this PR though.

https://github.com/llvm/llvm-project/pull/139566