Provides an opt-in mechanism to allow parsers to support dynamically
resolving variables at runtime. While this defeats some of the
static compile type benefits that typical guarantees, it is required
to allow existing parsers to be converted to use typical.
The existing resource parsers allow searching for variabls by their
fully qualified path. For example, the hostname of a server may
be quiered via `resource.spec.hostname`. In order to support this
typical could use some reflection to automatically add variables
to every nested field but that would be complicated and expensive.
Instead the ParserSpec can now be configured with
`GetUnknownIdentifier`, which allows creators of the parsers to
have full control over how a dynamic variable is resolved. The
parser prevents any dynamic resolution if the value is not configured
to limit the unsafe behvior to only parsers that explicitly opt in.
Prefer the stdlib version of the experimental package.
Includes a depguard update to prevent future regressions,
as well as an e-ref update to appease depguard.
Generated with:
$ gofmt -w -r '"golang.org/x/exp/slices" -> "slices"' . && \
make fix-imports
* feat: library for building predicate parsers
Took some things I learned while building Login Rules and implemented a
library that can be used to quickly implement new and improved predicate
parsers.
Copied from the package comment:
typical (TYPed predICAte Library) is a library for building better
predicate expression parsers faster. It is built on top of
[predicate](github.com/gravitational/predicate).
typical helps you (and forces you) to separate parse and evaluation into
two distinct stages so that parsing can be cached and evaluation can be
fast. Expressions can also be parsed to check their syntax without
needing to evaluate them with some specific input.
Functions can be defined by providing implementations accepting and returning
values of ordinary types, the library handles the details that enable any
function argument to be a subexpression that evaluates to the correct type.
By default, typical provides strong type checking at parse time without any
reflection during evaluation. If you define a function that evaluates to
type any, you are opting in to evaluation-time type checking everywhere that
function is called, but types will still be checked for all other parts of
the expression. If you define a function that accepts an interface type it
will be called via reflection during evaluation, but interface satisfaction
is still checked at parse time.
* fix typo in error message
Co-authored-by: Tim Buckley <tim@goteleport.com>
---------
Co-authored-by: Tim Buckley <tim@goteleport.com>
rosstimothy