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>
Previously, the format package would return an error if any of the AST
nodes under the input were missing a location value. When the format
package was first implemented, the main use case was formatting policies
that people had written manually--which means they are provided to OPA
as files/raw strings. As a result, it made sense to treat a missing
location as an error condition because it simplifies the formatting
implementation.
However, when policies are generated (e.g., by partial evaluation) the
AST nodes do not typically carry locations. As a result, these AST nodes
cannot be formatted nicely.
These changes modify the format package to tolerate nil location values.
If a nil location value is encountered, the format package will set the
location value on the AST node to a default location, currently row 1
column 1 with text from the AST node's string representation.
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
Previously, if an empty ast.Body was passed to the formatting package,
it would trigger a panic because the location getter would try to index
into an empty slice.
These changes make the location getter tolerate empty bodies and the
format package tolerate nil locations on empty bodies. The changes also
improve simplify the error message when nil locations are found.
Fixes#909
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>
Previously, sets and objects were not interfaces and as a result,
callers were relying on the underlying structure for operations such as
iteration.
These changes refactor the ast package to expose sets and objects as
interfaces so that we can change the underlying data structures without
affecting callers.
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
These changes update the AST to represent function names as refs.
Previously, function names were represented as strings. Representing the
names as strings was fine, however, once functions and rules are
merged, it will be desirable to refer to functions using references.
This is a bit of preemptive refactoring to make that change easier.
Instead of having functions referred to with both strings and
references, all functions will be referred to with references.
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.
The new version of mna/pigeon fixes the location bug that prevented
accurate line/column numbers from being reported on unmatched input.
In the future we can investigate improvements to the error messages by
adding negative matches that return higher-level errors as long as the
location information is not impacted.
Fixes#214
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.