Fix issue 20261 - lambda function error message is confusing

[usefahmed07]

Fixes #20261

[kinke]

I don't think this is an improvement, let alone totally inconsistent if only done here, or selectively for a few other messages.

[usefahmed07]

Contributor

Thanks for the feedback. Just to understand better — do you think the original __lambda3(__T1) name was fine as-is, or is there a different way you'd want it changed (keeping the location/type info but dropping just the compiler-generated parts)?

[kinke]

My main problem is the inconsistency - either we print all lambdas in a generic fashion without the internal identifier, with its line+column suffix, everywhere (for all diagnostics, and implemented only once), or we keep things as is - which I'd prefer, since the line number can be handy at times (it's the line where the lambda starts).

The original #20261 is about the internal counter suffix that we used back then, instead of that line+column suffix nowadays. So I think it's invalid nowadays, even though it's certainly confusing that for that specific error message, the template declaration seems to be printed, not the template instance, where the T1 type parameter would be bound to a specific type. Printing the full lambda as suggested in that original issue is IMO not an option, since a lambda can stretch over many lines.

[kinke]

Looking again at the original code in the issue, I doubt that printing the template instance is easily feasible here - inferring the type for untyped parameter x requires the assignment to the function pointer (expecting an int param), but the error might likely occur earlier, while checking the lambda body and coming across the invalid use of the captured local.

But feel free to try to improve that. :)

[usefahmed07]

Looking again at the original code in the issue, I doubt that printing the template instance is easily feasible here - inferring the type for untyped parameter x requires the assignment to the function pointer (expecting an int param), but the error might likely occur earlier, while checking the lambda body and coming across the invalid use of the captured local.

But feel free to try to improve that. :)

Tried it — it actually works. Added a debug printf and confirmed the TemplateInstance's tiargs are already resolved by the time the error fires.

For example, with:

int function(int, int) fp = (x, y) => x + y + c;

Current output shows the unbound template declaration:

__lambda_L4_C33(__T1, __T2)(x, y)

Switching toPrettyChars() to use the instance instead of the declaration gives:

__lambda_L4_C33!(int, int)

Location is kept, and the placeholder types (__T1, __T2) become the actual resolved ones (int, int).

I'll push this to this PR instead of the generic "lambda function" approach, unless you'd prefer something different.