The formatter was not starting a new line after writing comments that
preceed an expression. As a result the first part of the expression
written (e.g., "not", function name, "some", etc.) would be written
without any indentation.
Fixes#1560
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
This commit renames the 'var' keyword to 'some'. 'some' is more
descriptive than 'var' and will better complement an 'every' or
'forall' keyword representing for universal quantifiers.
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
Previously trailing comments inside arrays, objects, and sets were not
being formatted correctly. For example:
[
1,
2,
# foo
]
Would result in:
[
1,
2,
# foo ]
The problem was that when the sequence was ended, the comments were not
being emitted. As a result when the comments were finally emitted, the
indenting was wrong and the state of the formatter was not consistent
(and so the closing bracket appeared on the same line the comment.)
These changes modify the formatter to emit the comments when ending the
sequence, as that's the point where the indenting state is known.
Also, as part of these changes, the fix for extra newlines (#1032) has
been modified. Instead of changing the startLine and endLine behaviours
(which are a bit sensitive) we just squash trailing newlines at the end
of the formatting process.
Fixes#1060
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
If the rule defines a constant value or is part of an incremental
definition, then the value must not be elided because that would result
in a syntax error or change the meaning of the rule.
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
The formatter was not handling else statements for functions properly.
The function args were being written after the else keyword which
resulted in rules that did not parse.
Previously, functions were implemented with a separate set of types that
had their own code paths in the compiler, eval, etc. These changes
refactor the function implementation so that functions are implemented
as rules with one or more arguments.
By representing functions as rules, we can avoid special casing required
to support functions, e.g., during parse and compile there are a number
of steps that required special casing for functions:
- Parser needed separate grammar definitions for functions (which
prevented them from being chained or using else)
- Compiler needed separate resolver and type checker implementations
which was a source of bugs.
In some cases, special casing is unavoidable for now (e.g., during eval)
however this could be improved in the future.
Fixes#471Fixes#467Fixes#463
Do not format strings before writing them to output. String formatting
was only being used for concatenation and caused problems for Rego
strings that contain printf verbs.
These changes allow partial docs to be defined without a body in Rego
source files. Before, the rules would have to include a `{true}` body
for the parser to allow them. Now, the body can be omitted.
Rules defined this way (inside modules) cannot be copy/pasted as-is into
the REPL. This could be addressed by creating a "paste mode" in the REPL
similar to ipython and other interactive shells.
These changes build on https://github.com/open-policy-agent/opa/pull/412
with a few differences:
- Dynamic values are allowed in the head.
- Partial sets are allowed.
Both of these changes are based on personal experience writing policy.
Dynamic values are fine to allow as the compiler will catch unsafe vars
and rewrite the head to handle refs and comprehensions.
This patch also fixes a bug in format which would cause comments
to be printed after a function or rule if they had an object or
set literal in their input set.
Objects and sets use curly braces to group their elements, and so format
mistook the bounds of the object or set inputs as the bounds of the
function/rule body (which also uses curly braces to group). This caused
the discovered closing location of rules and functions to be on an
earlier line than in reality, causing comments at the end to be written
after the body, not inside it.
This has been fixed, as the heads of functions and rules are skipped
before scanning for their closing braces.
When parsing, OPA transforms constants into rules with only the
expression `true` in the body. This is not desirable behavior, as
it's much cleaner for them to be expressed in the shorthand.
This patch also adds a test for parsing invalid rego.
Torin Sandall