I don't know if this is a bottleneck IRL, but while doing some
performance testing I noticed that this method allocates a bunch of
objects and I decided to fix it.
Here is the benchmark I used:
```ruby
require_relative 'theme_runner'
Liquid::Template.error_mode = ARGV.first.to_sym if ARGV.first
profiler = ThemeRunner.new
def count_alloc
before = GC.stat(:total_allocated_objects)
yield
GC.stat(:total_allocated_objects) - before
end
profiler.render # heat
p count_alloc { profiler.render }
p count_alloc { profiler.render }
p count_alloc { profiler.render }
```
Before this change:
```
[aaron@tc-lan-adapter ~/g/liquid (master)]$ ruby -I lib performance/run_once.rb
15753
15750
15752
```
After this change:
```
[aaron@tc-lan-adapter ~/g/liquid (master)]$ ruby -I lib performance/run_once.rb
14015
14010
14011
```
About an 11% reduction in allocations for this test. I also added some
tests around the current behavior of the method so we can be more sure
the replacement behaves the same way
The ParseTreeVisitor exposes the liquid internals that won't be
kept compatible with liquid-c, so move it out of the integration
tests directory so that we can easily ignore it when testing liquid-c
* Allow default function to handle false as value
* Change to named parameter
* Remove redundant freeze
* add brackets to make intention clearer
* Use named param format from liquid
* Update syntax
* document default filter
* Disable rendering of tag based on register
* Improvements to disable tag
* Resolve disbale tag tests
* Test disable_tags register
* disabled_tags is now always avaiable
* Allow multiple tags to be disabled at once
* Move disabled check to block_body
* Code improvements
* Remove redundant nil check
* Improve disabled tag error output
* Improve disable tag API
* Code improvements
* Switch disabled? to not mutate output
* Fix array handling shortcut in disable_tags
Example:
```
// the_count.liquid
{{ number }}! Ah ah ah.
// my_template.liquid
{% for number in range (1..3) %}
{% render "the_count", number: number %}
{% endfor %}
Output:
1! Ah ah ah.
2! Ah ah ah.
3! Ah ah ah.
```
The `render` tag is a more strict version of the `include` tag. It is
designed to isolate itself from the parent rendering context both by
creating a new scope (which does not inherit the parent scope) and by
only inheriting "static" registers.
Static registers are those that do not hold mutable state which could
affect rendering. This again helps `render`ed templates remain entirely
separate from their calling context.
Unlike `include`, `render` does not permit specifying the target
template using a variable, only a string literal. For example, this
means that `{% render my_dynamic_template %}` is invalid syntax. This
will make it possible to statically analyze the dependencies between
templates without making Turing angry.
Note that the `static_environment` of a rendered template is inherited, unlike
the scope and regular environment. This environment is immutable from within the
template.
An alternate syntax, which mimics the `{% include ... for %}` tag is
currently in design discussion.
An isolated subcontext inherits the environment, filters,
and static registers of its supercontext, but with a fresh
(isolated) scope.
This will pave the way for adding the `render` tag, which renders
templates in such a subcontext.
