Add bare-bracket rejection to Parser#expression in strict2 mode, so that
`['var']` is disallowed and `self['var']` is the required syntax.
- Add `Expression::SELF` constant ('self')
- Add `Parser#reject_bare_brackets` option, checked in `expression`
- Add `ParseContext#reject_bare_brackets?` and `force_reject_bare_brackets`
- Add `VariableLookupDrop` for `self['var']` scope-chain lookups
- Add `Variable#==` for rewriter state comparison
- Update `Context#find_variable` to return `VariableLookupDrop` for `self`
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
This commit reverts the Inline Snippets tag (#2001) and bumps
Liquid to 5.11. For now, the inclusion of Inline Snippets
in the latest Liquid release is being treated as a bug.
While #2001 does implement the scope contained in RFC#1916,
we need to take a step back to make sure we’re setting our
sights high enough with this feature, and that we’re truly
supporting theme developers in the ways they need.
If you have any feedback, please leave a comment on RFC#1916.
- Liquid Developer Tools
This commit adds a new tag named `#` that behaves like a comment.
Therefore it behaves as you'd expect any tag would work. The difference
with the comment tag is that the comment is in the tag markup and that
there is no block delimiter.
What it looks like in practice:
```liquid
{%- # this is an inline comment -%}
{% # this too is an inline comment %}
{% liquid
# required args:
assign product = product
# optional args:
assign should_show_border = should_show_border | default: true
assign should_show_cursor = should_show_cursor | default: true
%}
{% liquid
# This is a very long comment that spans multiple lines.
# It looks very similar to what it would look like if you wrote
# ruby code instead of liquid. But it doesn't have all the clunk
# of having an open tag and a close tag with so many characters.
%}
```
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.
Liquid::C parses liquid filter arguments with dashes in them, Liquid does not.
For tags that accept kwargs and dumps them on the HTML tag, this is an important feature.
e.g. {{ ... | image_tag: loading: 'lazy', data-something: 'value!' }}
Without this change, Liquid would incorrectly parse the
`data-something` kwarg as a single argument and would skip over the
invalid characters.
See https://github.com/Shopify/theme-check/issues/539 for more context
* 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.
Tobi Lutke