https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93275
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #5)
> (In reply to Martin Liška from comment #3)
> > Confirmed, started with r9-6404-g1ce59b6cad83d5ca6f1efee83f910d8b677a976a.
>
> Are you sure? It's only a daily bump.
Sorry, it's the commit right after it:
r9-6405-gbddee796d0b4800b5ac3d7e7e9e315c23799424d
For named function calls in a template, the result of unqualified lookup is
safed in CALL_EXPR_FN. But for operator expressions, no unqualified lookup
is performed until we know whether the operands have class type. So when we
see in a lambda a use of an operator that might be overloaded, we need to do
that lookup then and save it away somewhere. One possibility would be in
the expression, but we can't really add extra conditional operands to
standard tree codes. I mostly implemented another approach using a new
WITH_LOOKUP_EXPR code, but teaching everywhere how to handle a new tree code
is always complicated. Then it occurred to me that we could associate the
lookups with the function, which is both simpler and smaller. So this patch
stores any operator bindings needed by a lambda function in an internal
attribute on the lambda call operator.
* name-lookup.c (op_unqualified_lookup)
(maybe_save_operator_binding, discard_operator_bindings)
(push_operator_bindings): New.
* typeck.c (build_x_binary_op, build_x_unary_op): Call
maybe_save_operator_binding.
* decl.c (start_preparsed_function): Call push_operator_bindings.
* tree.c (cp_free_lang_data): Call discard_operator_bindings.
From-SVN: r269477
