Sometimes a consumer of a template needs to know what objects were used.
In my case, a template can reference secret values from a secret store
vault and instead of passing all possible secrets to the template only
to render two of them, we use the ast to determine which are used and
only retrieve those values from the vault before rendering the template.
Exposing the ast allows us to use the liquid APIs just like normal,
without having to jump through hoops to build the ast ourselves using
the other types exported in this library.
Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>
This fixes an issue where math.MaxUint32 is assigned to a platform
dependent int type. This works on 64-bit platforms without issue due to
there being plenty of space. On 32-bit platforms this is wrong and will
not compile as math.MaxUint32 > math.MaxInt32.
This fixes an issue where math.MaxUint32 is assigned to a platform
dependent int type. This works on 64-bit platforms without issue due to
there being plenty of space. On 32-bit platforms this is wrong and will
not compile as math.MaxUint32 > math.MaxInt32.
When user-defined function is called, it does convert all the arguments using
MustConvert, which panics on error with an error. However 'func (e expression)
Evaluate(ctx Context)' from sub package "expressions" catches those panics and
converts some of them to errors. Raw errors returned from strconv functions
are "repanicked", but proper error types such as values.TypeError are not.
Hence we should use it here.
Go's reflect API is very picky about arguments to Call method. You can't just
pass in the "int" when function expects "int64", even on 64 bit machines. This
patch solves this problem by performing conversions properly. Truncation
problems however, as well as negative to uint issues are completely ignored.
Which is perhaps not ideal, but still better than returning "int" when "int32"
or "int64" is requested.
I did split the Kind switch cases and moved value -> int and value -> float
conversions to separate functions. An alternative to that would be using the
reflection API, which might be less performant. Not that it matters much, but
this solution is correct, even though looks a bit copy & pasty.
Oh and of course all "uint" types were completely missing in the function and
they are now added.
This commit addresses two issues:
1. For variadic functions 'convertCallArguments' was allocating exactly
'len(args)' arguments, which might be less than required, as a result
zero/default filling loop would panic with out of bounds error.
2. Even if we correctly allocate a proper amount of arguments, zero/default
filling loop doesn't handle special variadic function type case, when last
argument has a slice type and reflect API expects plain values as arguments.
But actually we don't need that, because it's okay to omit variadic values
altogether, hence the total amount of allocated arguments is
max(len(args), rt.NumIn()-1).
