IWYU should not recommend <new> when using size-aware operator delete

[adembo]

According to https://en.cppreference.com/w/cpp/memory/new/operator_delete, the C++14 size-aware operator delete functions are in the set of functions that are implicitly declared in each translation unit even if the <new> header is not included. And yet, if you use them and run IWYU, it recommends including <new>.

The incorrect recommendation appears to be rooted in iwyu_ast_util.cc's IsDefaultNewOrDelete function, which includes this code:

// Placement-new/delete has 2 args, second is void*.  The only other
// 2-arg overloads of new/delete in <new> take a const nothrow_t&.
if (decl->getNumParams() == 2 &&
    !decl->getParamDecl(1)->getType().isConstQualified())
  return false;

For the size-aware operator delete functions, there are two parameters and the second is a (non-const) size_t, which causes IWYU to return false here and recommend the inclusion of <new>.

My guess is that this function was written pre-C++14 and hasn't been revised since. I've been working on a patch to update it; will submit a separate PR.

[kimgr]

We did lots of research in the context of PR #778, and learned the following:

• new and delete have two family trees: one as overloadable operators, and one as expressions, whose semantics are built into the language.
• the semantics of new X; is to first call operator new for X, whether built-in or user-defined, to allocate memory, and then execute X's constructor.
• operator new(size_t) is declared in <new>, but its declaration is made implicitly available by the compiler, as well as a definition, if none is provided by the user. This is called a 'replaceable allocation function'.
• operator new(size_t, void*) is the non-allocating allocation function for placement syntax, i.e. new (<some pointer>) X; -- again, it calls the (noop) allocation function, and then executes X's constructor.
• operator new(size_t, void*) is defined in <new>, and so can't be replaced/overloaded.
• There are also placement-like operators provided to enable syntax new (std::nothrow) X; and new (std::align_val_t(32)) X;, but these are replaceable (so that the user can provide custom allocation with alignment no-throw guarantees)
• Finally, while you can't replace the global placement allocation function, you can overload it for more specific types, e.g. void* operator new(size_t sz, Arena& arena);. Used like this new (arena) X;, it could delegate allocation to an arena that's more efficient than built-in malloc.
• The compiler is really helpful with the replaceable functions; their declarations are implicitly available and a definition is generated unless one is already provided by the user
• One exception to the above bullet is std::nothrow and std::align_val_t -- these two symbols are not made implicitly available, you need to explicitly #include <new> to use them (there is a special case for C++17 where the std::align_val_t overload is implicitly used if the type being new-ed has alignment restrictions. No include necessary in that case.)
• The other exception is ::operator new(size_t, void*) -- as it is both trivial and not replaceable, the standard library forces one definition into the translation unit when <new> is included.

Note that it is possible to define your own ::operator new(size_t, void*), so in some sense it is replaceable in practice.

All this said, for IWYU there's a few simple rules:

• If the user employs normal placement new -- ::operator new(size_t, void*), using e.g. char buf[128]; new(buf) X; -- they should include <new> to get the definition in place. Because no other symbols indicate where the declaration should come from, we need a special rule in IWYU to recognize placement new and map it to <new>.
• If the user employs no-throw or aligned new (which kind of look like placement), they spell std:: symbols, which will lead IWYU to <new> by its normal logic. No special handling necessary.
• All other allocation functions and new-expressions are handled implicitly by the compiler, and require no additional includes.

This is reflected in PR #784.