Implement {% do %}
blocks and fix {% set %}
block scoping
#1030
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These are to inline do tags as set blocks are to inline set tags.
They run the block of code within their body and then discard the output. This is done without going into a child scope so variables that are set here will persist their values outside of the do block. This is unlike a
{% for %}
tag or a macro function execution.This is also supposed to be unlike a set block, which, in jinja, executes in a child scope. I realised that we were not running set blocks in a child scope and so I wanted to fix that to have parity with jinja. However, we were using set blocks in eager execution to be able to execute code, while ignoring the string output. This is useful for
{% extends %}
,{% from %}
and{% import %}
as it would allow us to retain any deferred modifications that happened as a result of using those tags without adding any extra output. But this also hinged on the lack of child scoping that set blocks currently use. So the need for a solution where we could ignore the output, keep the current scope, and fix the scoping of set blocks to match their functionality in jinja arose. Implementing do blocks fit the bill perfectly, and we can continue not using a child scope when executing set blocks with that__ignored__
variable name so as to not break any previous eager renders that used that.Additionally, after realising that deferred macro functions should be put into their own scope #1020, I have been working through another bug the past couple days and found that it's simpler to instead just use the macro function temporary variable functionality I added in #920, which should scope the modifications done in the macro function properly. That's how I realised that the bug with set blocks existed because that didn't work as it was supposed to.