-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bind custom operators between mul
and unary
#895
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assertThat(interpreter.render("{{ (-5 * -4 | abs) }}")).isEqualTo("-20");
I think the filter operation should be at the same level as unary
rather than the same level as mul.
Might make sense to add a new filter(boolean required)
method and have mul()
point to that instead of unary()
and have the filter method call unary and do the |
and is
logic
src/test/java/com/hubspot/jinjava/interpret/JinjavaInterpreterTest.java
Outdated
Show resolved
Hide resolved
Thanks for the extra test case! I confirmed Jinja indeed returns -20 here.
I think you mean filters should bind tighter than Your implementation suggestion sounds good to me, I'll try that out. |
mul
precedencemul
and unary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Closes #893
Currently, our custom operators like
|
andis
bind tighter than unary operators. This means-1 is integer
incorrectly evaluates like-(1 is integer)
, leading to an error when Jinjava tries to maketrue
negative. This is because these operators are defined withinvalue
which is called byunary
, and therefore have precedence greater than the unary operators.This PR pulls our custom operators up from the
unary
level of the JUEL grammar to themul
level. This means they bind tighter thanmul
but less tightly thanunary
. From my testing, this aligns with Jinja's precedence rules.