On Fri, Mar 8, 2019 at 8:04 AM Nathan Sidwell <nat...@acm.org> wrote: > > On 3/7/19 9:54 PM, Jason Merrill wrote: > > 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. > > > > Tested x86_64-pc-linux-gnu, applying to trunk. Nathan, does slipping these > > bindings into the sk_function_parms binding level this way make sense to > > you? > > oo sneaky, I like it. Perhaps a comment explaining the surprising scope > these are being pushed into?
The comment for push_operator_bindings already says "push the bindings we saved away in maybe_save_op_lookup into the function parameter binding level", are you thinking of something else/more detailed? Jason
