Defining new names in namespace std is technically a non-conforming extensions. This makes it difficult for libc++ to backport C++20 destroying delete.
This patch should make it easier for libc++ to support destroying delete as an extension.
Currently Clang unconditionally defines __cpp_impl_destroying_delete. Unlike aligned allocation or sized deallocation which can be turned on or off by user.
I believe we should make destroying delete act similarly. It should be off prior to C++20 and we should provide flags for enabling destroying delete prior to C++20.
This patch does just that.
There are some weird corner cases though. What should Clang do when it sees a destroying delete overload but LangOpts.DestroyingDelete isn't enabled?
My current approach is to tolerate it's existence, but ignore it for the purposes of overload resolution (after emitting a warning).
With this patch, if Clang see
When a destroying delete function is found
Just use the AST context you have above ?