Re: PATCH: Fix two-phase lookup for "operator new"

[Andrew Pinski <pinskia at physics dot uc dot edu>]

> 
> 
> This patch fixes a two-phase name lookup problem with calls to new.
> In particular, the choice of function to call for "new T" should be
> resolved at parse time, if T is not a dependent type.  We were
> incorrectly deferring that to template instantiation time.  
> 
> To make this tidy, I eliminated the after-the-fact processing where we
> tried to poke at the CALL_EXPR generated by lowering the
> new-expression, and, instead, arrange that build_new_method_call tell
> us what function it decided to call, since it knows the answer.
> 
> While fixing this, I took the opportunity to eliminate a (small) waste
> of memory; build_new created a NEW_EXPR, just to pass it to
> build_new_1, which promptly took it apart again.  I also changed a
> diagnostics to refer to "incomplete" types rather than "undefined"
> types, since the former has a well-defined meaning, and the latter is
> ambiguous; it could mean either a type that has not been declared, or
> an incomplete type.
> 
> Tested on x86_64-unknown-linux-gnu, applied to mainline.  (AFAIK, this
> is not a regression, so I am not planning to backport it to 4.1.  If
> it is a regression, then we'll want to backport only the essential
> bits of the patch.)

This only fixes operator new, correct?  PR 21802 shows that this is a
problem with any kind of operator and not just operator new.  Just 
something to keep in mind for the future if you missed that bug before.

-- Pinski