-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
repl: nested expressions not assigned with = #1104
Labels
Comments
tsandall
changed the title
repl: nested expressions not assigned with = but are :=
repl: nested expressions not assigned with =
Dec 10, 2018
Isn't this a duplicate of #726? It does have more information, though; we could consider merging them. 🤔 |
@srenatus indeed. I'm going to close the other one in favour of this one. |
tsandall
added a commit
to tsandall/opa
that referenced
this issue
May 19, 2019
In the process this addresses an issue where nested expressions are not assigned. Fixes open-policy-agent#1104 Signed-off-by: Torin Sandall <torinsandall@gmail.com>
tsandall
added a commit
to tsandall/opa
that referenced
this issue
Aug 7, 2019
While adding support for the some keyword in the REPL and fixing open-policy-agent#1104 there was a regression where statements like `input = 1` would always be interpreted as rules. We made a decision a long time ago that the first time an expression like `input = 1` was encountered that a rule would be declared but that subsequent similar expressions (e.g., input = 1 or input = {"foo":"bar"} or ...) would perform a comparison. The regression broke this for cases where the left hand side was a reference to a global document (i.e., input or data). This commit just fixes the regression by updating the global check to account for refs. Signed-off-by: Torin Sandall <torinsandall@gmail.com>
tsandall
added a commit
that referenced
this issue
Aug 7, 2019
While adding support for the some keyword in the REPL and fixing #1104 there was a regression where statements like `input = 1` would always be interpreted as rules. We made a decision a long time ago that the first time an expression like `input = 1` was encountered that a rule would be declared but that subsequent similar expressions (e.g., input = 1 or input = {"foo":"bar"} or ...) would perform a comparison. The regression broke this for cases where the left hand side was a reference to a global document (i.e., input or data). This commit just fixes the regression by updating the global check to account for refs. Signed-off-by: Torin Sandall <torinsandall@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
Nested expressions that look like assignment should be treated as such in the REPL.
Actual Behavior
Nested expressions are evaluated as queries. For example, the following expression does not define a new rule 'x'.
As a top-level statement in a Rego file, 'x' would be defined as a rule.
Additional Info
This is likely an issue to do with the evalStatement function in the REPL where we try to convert AST statements into rules. If the statement is rewritten as
x := 1+1
then a rule is defined as expected.Note, in
x = 1+1
'x' could refer to another rule in which case the statement should just be evaluated. The REPL should compile/resolve references in the statement and then rely on the parsed AST to decide whether a rule should be defined.The text was updated successfully, but these errors were encountered: