From the commit message:

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.

While this commit fixes existing behaviour, i.e. implicit conversions from strings to ints. What worries me is that errors from strconv.ParseInt(value, 10, 64) and strconv.ParseFloat(value, 64) are returned directly here. I didn't change that behaviour in this patch, but perhaps it would be wise to do so. What do you think, @osteele? Perhaps it would be better to convert those errors into TypeError, so that they are properly caught in func (e expression) Evaluate(ctx Context), instead of causing unnecessary panics?

Anyways, I think I will submit a follow up pull request in a sec if you think it might be a good idea.

I would like to be able to customise the delimiters I use in templating (this is intended as an analog of https://golang.org/pkg/text/template/#Template.Delims).

This PR has the following problems

1. Delimiters is a byte array to limit them to single ASCII characters
2. The tag delimiters are formed using the objectLeft and objectRight argument, I would like to specify all 4 combinations completely, e.g., "<<", ">>", "<%", "%>".
3. I think moving compilation of the tokenMatcher regex into the function call will dramatically slow things down.
4. There are no tests. I did it like this so I didn't have to change the existing code much.

I am happy to continue work on this, but I'm lodging a PR to see if you're willing to accept this sort of functionality, if I'm going about implementing in the right way, and to check if I haven't missed some other locations where the delimiters are hardcoded.

Checklist

• [x] I have searched the issue list
• [ ] I have tested my example against Shopify Liquid. (This isn't necessary if the actual behavior is a panic, or an error for which IsTemplateError returns false.)

Expected Behavior

I can compile for armv7

Actual Behavior

Throws error: yaccpar:452: constant 4294967295 overflows int

Detailed Description

It appears somewhere there's a constant which is too large for anything but a 64bit environment.

Possible Solution

Would be good to add some build tags to have a different value for other environments.

Add a godoc example that demonstrates how to list variable names used.

I realized when I wrote this example that it works great for us since we don't use expressions in templates like {{ myvar | capitalize }}. It doesn't work for expressions but it could if I exported a few more values so that I can get the bindings used in the expression context.

I can submit a PR to add a few more getter functions to make this example work for more templates if that's something you would consider merging?

Below is a screenshot of the example rendered in godoc

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [ ] Performance improvements include benchmarks. (NA)
• [ ] Changes match the documented (not just the implemented) behavior of Shopify. (NA)

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.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [x] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

See

• https://shopify.github.io/liquid/filters/floor/
• https://shopify.github.io/liquid/filters/ceil/

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [x] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

When a Filter returns an error as its second argument it generates a panic with the error.

I have changed this behaviour so that the error is returned from the RenderAndPass function.

For example, if there is a filter called toTitle that returns "test error" as its error, the error returned will be 'Liquid error: error applying filter "toTitle" ("test error") in {{ "test message" | toTitle }}'.

Apologies if panicing in this case is the expected behaviour and this was done intentionally, I can always just catch the panic when I call the Render step, I just think this way is more elegant.

Currently

	params := map[string]interface{}{
		"message": Message{
			Text: "hello",
		},
	}
	engine := liquid.NewEngine()
	template := "{{ message.Text }}"
	str, err := engine.ParseAndRenderString(template, params)
	log.Printf("Err: %v\n%v", err, str)

doesn't work as expected, but

	params := map[string]interface{}{
		"message": map[string]interface{}{
			"Text": "hello",
		},
	}
	engine := liquid.NewEngine()
	template := "{{ message.Text }}"
	str, err := engine.ParseAndRenderString(template, params)
	log.Printf("Err: %v\n%v", err, str)

does. The text/template and html/template libraries in the go standard library allow you to traverse through any objects (maps, structs, slices and pointers to these) and use them in the templating engine, as in my first example.

A decent workaround for this is the github.com/fatih/structs Map() function, which converts your struct structure into a map based structure, but this has two problems in my use case. 1. My data struct is very large and this is a lot of processing, and 2. it preserves elements of my data struct that are *map[string]interface{} (which need to be like this to work with the rest of my program), which as far as I can tell

	params := map[string]interface{}{
		"message": &map[string]interface{}{
			"Text": "hello",
		},
	}
	engine := liquid.NewEngine()
	template := "{{ message.Text }}"
	str, err := engine.ParseAndRenderString(template, params)
	log.Printf("Err: %v\n%v", err, str)

also doesn't work correctly.

Are you planning on extending to copy this behaviour (from text/template or even https://github.com/acstech/liquid) in your current library, or do you consider it out of scope?

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.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [ ] Performance improvements include benchmarks. N/A
• [ ] Changes match the documented (not just the implemented) behavior of Shopify. N/A

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).

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [x] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

See https://ci.appveyor.com/project/osteele/liquid:

# github.com/osteele/liquid/strftime
could not determine kind of name for C.localtime_r
Command exited with code 2

The Ruby implementation has support for erroring when a template has an undefined variable. This is implemented by passing an option to the render() method.

As this version doesn't expose render.Config in the engine, a StrictVariables() method is provided on the engine to enable it. This differs from the Ruby version in that it's on for the entire engine, rather than enabled for each call to Render(). This is more similar to the Ruby version's render!() method as it immediately errors, rather than storing a stack of errors which can be accessed later.

Refs. #8

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

slice was broken with an offset or length above 1000. Shopify documents that slice supports arrays in addition to strings; I added support for working on slices.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes. (at least on modified files)
• [x] New and changed code is covered by tests.
• [ ] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

The previous map implementation worked only for slices of maps. By using the library's values package this implementation should work with all compatible types.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes. (at least on modified files)
• [x] New and changed code is covered by tests.
• [ ] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

This pull request adds auto-escape functionality which is similar to implicitly applying a filter to the output of an expression block, but done in a slightly efficient way (using a mechanism similar to strings.Replacer which allows for streaming processing without excessive memory allocations).

I know this functionality is not part of liquid (there is an open issue which doesn't have any responses at the time of writing), but I think this is an extremely useful feature and it does not break any existing functionality.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [x] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [x] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.

This PR adds the else clause to unless

Checklist

• [x] I have read the contribution guidelines.
• [x] make test passes.
• [x] make lint passes.
• [x] New and changed code is covered by tests.
• [ ] Performance improvements include benchmarks.
• [x] Changes match the documented (not just the implemented) behavior of Shopify.