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.
| 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.
There was a problem hiding this comment.
ok i thought this is outside the "arg0 is receiver" branch, but if the inconsistency with EvalVarArgs is fine, then ok
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.