-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[Cedar 3.0] Desugaring of greater-than operator changes evaluation order #112
Comments
mattmccutchen-amazon
added
the
pending-triage
The cedar maintainers haven't looked at this yet. Automicaly added to all new issues.
label
Jun 6, 2023
andrewmwells-amazon
added
the
bug
Something isn't working. This is as high priority issue.
label
Jun 6, 2023
2 tasks
khieta
added
pending-review
A Cedar maintainer has looked at this, but believes it needs review by more of the core team
backlog
and removed
pending-triage
The cedar maintainers haven't looked at this yet. Automicaly added to all new issues.
pending-review
A Cedar maintainer has looked at this, but believes it needs review by more of the core team
labels
Jun 6, 2023
andrewmwells-amazon
changed the title
Desugaring of greater-than operator changes evaluation order
[Cedar 3.0] Desugaring of greater-than operator changes evaluation order
Jul 12, 2023
john-h-kastner-aws
added a commit
that referenced
this issue
Nov 3, 2023
Fixes the evaluation order of operands to `>` and `>=` so that an error in the left operand will always be reported instead of any error which may exist in the right operand. `a > b` is defined as `!(a <= b)` instead of `b < a` and `a >= b` is defined as `!(a > b)` instead of `b <= a`.
john-h-kastner-aws
added a commit
that referenced
this issue
Nov 6, 2023
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Before opening, please confirm:
Bug Category
Cedar Parser
Describe the bug
The CST-AST conversion desugars
a > b
intob < a
anda >= b
intob <= a
. That changes the evaluation order, which is visible to users via its effect on which error gets reported if botha
andb
raise an error and possibly via performance differences as well. The effect on error reporting could be confusing to users: Cedar's evaluation order is generally left to right, so if an expressiona op b
raises an error fromb
, I think an average user might think that meansa
evaluated successfully and might get led down a wrong path during debugging.Expected behavior
When an expression of the form
a > b
is evaluated,a
should be evaluated beforeb
, as with most other Cedar binary operators.Reproduction steps
This can be reproduced using the
cedar
command-line tool:In both commands of this example, both the left and the right operand raise an error. The
<
operator propagates the error from the left operand, while the>
operator propagates the error from the right operand.Code Snippet
Included in the "reproduction steps".
Log output
Included in the "reproduction steps".
Additional configuration
No response
Operating System
Linux
Additional information and screenshots
A possible solution that doesn't require adding any more operators to the AST: change the desugaring of
a > b
to!(a <= b)
, and change the desugaring ofa >= b
to!(a < b)
.The text was updated successfully, but these errors were encountered: