Re: [cdt-dev] Computing return type for auto fold-expressions

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

> I'm creating the tree currently in the instantiate(InstantiationContext, int): 
> I get the instantiation point with CPPSemantics.getCurrentLookupPoint(), 
> get the ICPPASTFunctionCallExpression from there on and then the 
> evaluation of the function call where I get the evaluations from the 
> arguments from. 

That's very clever :) However, it's not how I intended CPPSemantics.
getCurrentLookupPoint() to be used.

I intended getCurrentLookupPoint() to be used for "declaredBefore" 
purposes only, that is, for determining whether a certain declaration 
occurs before or after the point of lookup; not as a general mechanism
for querying information about the call site without having to pass it
through the call chain.

In this case, it will also lead to incorrect results, as I explain below:

> Which part is not correct about that?

I would expect instantiate() to only be called once per set of concrete
argument *types* (as opposed to argument values).

For example:

template<typename... Args>
auto sum_fold(Args... args) { return (... + args); }

int main() {
    sum_fold(1, 2, 3);    // call #1
    sum_fold(4, 5, 6);    // call #2
}

Call #1 and call #2 call the same instantiated version of the function:
sum_args<int, int, int>. Since we cache template instances, we only
instantiate sum_args<int, int, int> once. If you bind the fold
expression to argument evaluations at instantiation time, you're
going to bind the evaluations "1", "2", and "3", including their _values_,
to the function sum_args<int, int, int>. If you then try to evaluate
call #2 (imagine the function is constexpr and you want the value the
function returns), it will still use the "1", "2", "3" values, even though
those now have incorrect values for this call.

This is why we need to use evaluations for the parameters rather
than the arguments.

Let me know if that helps clear things up.

Regards,
Nate