Solves Shopify/theme-check#582
`icon` should be visited in the render tag for the following snippet:
```liquid
{% assign icon = 'warning' }
{% render 'icon' with icon %}
```
Make Context use StaticRegisters by default. This makes it easier to
ensure that all subcontexts share the same static registers.
Co-authored-by: Dylan Thacker-Smith <[email protected]>
Including a module can cause Ruby's global constant cache to be busted
if the included module contain constants. So that's something you don't
want to happen at "runtime", otherwise it will severely degrade performance
and if you are using YJIT or MJIT most of the compiled code will be invalidated.
To limit the impact of this, we can pre-include the global filters,
as they're generally registered during boot, that limits the problem
to non-global filters.
This fixes theme-check#218, wherein variables used in echo tags are not
considered used by the linter. It is because our visitor doesn't see the
:variable_lookup's in the echo tag since the children array is empty.
But this array is empty because it is swallowed by the @variable.
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
* 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.
Michael Go