* fix(caddyfile): {block} in snippet
Resolve issue #7557
So, here is the situation:
- Pull request #7206 included some changes to the doImport's function of
Caddyfile's parser. What it does is that if there is no token within a
block that follows the import, and the import contains `{block}`, then
the `{block}` token is discarded.
- After this pull request:
- Issue #7518 noticed that in cases that `{block}` was not imported,
a runtime error was raised due to the assumption that tokens were
always added to `tokensCopy` on every iteration of `importedTokens`.
This was fixed by pull request #7543.
- Issue #7557 notices that {block} can be ignored when imported from a
certain file. There, it's again an issue with how the import works.
When `import snippets` is called, this import instruction doesn't
contains any nested blocks. And when the argument replacer that is
the `importedTokens` loop is called and finds `{block}`, it uses the
block from the file's import (which in this case is nothing),
`{block}` is erased, and unavailable when the import directive is
called for the imported snippet.
The changed in this commit addresses the second issue by checking before
replacing `{block}` if we're currently in a snippet definition, and
appending the `{block}` token to `tokensCopy` if we are.
With this changes, when importing those snippets, the `{block}` token
will be available to be replaced by the nested blocks in `tokensToAdd`
if needed, or erased if there are no nested blocks and `tokensToAdd` is empty.
Tests added in pull requests #7206 and #7543 passes with this new
implementation, confirming that unused `{block}` are accepted if nothing
is passed to `import`, as well as the other usual tests.
A new test was also added based on issue #7557 reporting, and also passes.
Signed-off-by: prettysunflower <me@prettysunflower.moe>
* caddyfile: add imported snippet block placeholder coverage
---------
Signed-off-by: prettysunflower <me@prettysunflower.moe>
Co-authored-by: Zen Dodd <mail@steadytao.com>
