Specialize receiver varargs fallback#934
Conversation
Route unresolved varargs calls through a receiver-specific evaluator that avoids building the full argument array before receiver dispatch. Also pass the complete receiver tail to dynamic receivers and cover unchecked receiver varargs calls with multiple arguments.
|
|
||
| private Val receiveOrNoSuchOverload(Val arg0, Val... tailArgs) { | ||
| for (Val argVal : tailArgs) { | ||
| if (isUnknownOrError(argVal)) { |
There was a problem hiding this comment.
nit: this check seems unnecessary as tailArgs has been checked for errors already
| if (arg0.type().hasTrait(Trait.ReceiverType)) { | ||
| return ((Receiver) arg0).receive(function, overload, tailArgs); | ||
| } | ||
| return noSuchOverload(arg0, function, overload, tailArgs); |
There was a problem hiding this comment.
the existing EvalVarArgs calls this with all arguments, not just the tail:
https://github.com/snazy/cel-java/blob/f130b4db348f23e019d98b08fe21a41d7dce620e/core/src/main/java/org/projectnessie/cel/interpreter/Interpretable.java#L764C1-L764C37
is this intentional or would this produce different errors?
There was a problem hiding this comment.
Yep, this produces a different error message, and that's intentional.
arg0 is already passed separately to noSuchOverload() as the receiver, so including it again in args duplicates the receiver type in the rendered signature.
Passing only tailArgs is consistent with EvalUnary, EvalBinary, and Receiver.receive().
The existing EvalVarArgs behavior looks inconsistent here.
2 participants
Route unresolved varargs calls through a receiver-specific evaluator that avoids building the full argument array before receiver dispatch.
Also pass the complete receiver tail to dynamic receivers and cover unchecked receiver varargs calls with multiple arguments.