Recursive macro calls, direct and indirect, would cause a stackoverflow.
This PR lets the macro call handler keep track of the stack of called
macros we are currently in, so we can abort with an error message
instead of panicking.
Not for all operations the nesting level was incremented when needed
and/or the un-incremented nesting level was used in subfunction calls.
Binary operators such as `*` did not properly increment the nesting
level.
This PR changes `Level` in such a way that it can be used to keep track
of the nesting level when used in a loop. It is now impossible to
accidentally refer to an old nesting level value.
Resolves <https://issues.oss-fuzz.com/issues/385256115>.
This PR adds an optional argument to the `|tojson` filter, which
controls if the serialized JSON data gets prettified or not. The
arguments works the same as flask's [`|tojson`][flask] filter, which
passes the argument to python's [`json.dumps()`][python]:
* Omitting the argument, providing a negative integer, or `None`, then
compact JSON data is generated.
* Providing a non-negative integer, then this amount of ASCII spaces is
used to indent the data. (Capped to 16 characters.)
* Providing a string, then this string is used as prefix. I attempts are
made to ensure that the prefix actually consists of whitespaces,
because chances are, that if you provide e.g. `&nsbp;`, then you are
doing it intentionally.
This is a breaking change, because it changes the default behavior to
not prettify the data. This is done intentionally, because this is how
it works in flask.
[flask]: https://jinja.palletsprojects.com/en/3.1.x/templates/#jinja-filters.tojson
[python]: https://docs.python.org/3/library/json.html#json.dump
I think previous input for filter-recursion ui test was not right as it
was not triggering error for recursion itself, for example:
```rust
fn fuzzed_filter_recursion() {
const TEMPLATE: &str = include_str!("../tests/filter-recursion.txt");
if let Err(e) = Ast::from_str(TEMPLATE, None, &Syntax::default()) {
panic!("{e}");
}
}
```
```sh
---- tests::fuzzed_filter_recursion stdout ----
thread 'tests::fuzzed_filter_recursion' panicked at rinja_parser/src/tests.rs:1121:9:
failed to parse template source at row 1, column 255 near:
"|A|AA|A|A|A|A|AA|A|A|A|A|AA|A|A|A|A|AA|A"...
```
This commit introduces a shorthand for defining and calling macros when
using them as a reusable substitute for variables assigned complex values
(e.g. string literals with or without newline escapes). The use-case is
formatting - from my experience it's easier to visually parse a `macro`
`endmacro` block than a multiline variable assignment.
Signed-off-by: mataha <mataha@users.noreply.github.com>
Just migrated a repo from tera to askama and this was one of the only
things that was different. This is also coherent with `{% block %}` for
which I added the same feature years ago.
Previously the built-in json filter had an issue that made it unsafe to
use in HTML data. When used in HTML attributes an attacker who is able
to supply an arbitrary string that should be JSON encoded could close
the containing HTML element e.g. with `"</div>"`, and write arbitrary
HTML code afterwards as long as they use apostrophes instead of
quotation marks. The programmer could make this use case safe by
explicitly escaping the JSON result: `{{data|json|escape}}`.
In a `<script>` context the json filter was not usable at all, because
in scripts HTML escaped entities are not parsed outside of XHTML
documents. Without using the safe filter an attacker could close the
current script using `"</script>"`.
This PR fixes the problem by always escaping less-than, greater-than,
ampersand, and apostrophe characters using their JSON unicode escape
sequence `\u00xx`. Unless the programmer explicitly uses the safe
filter, quotation marks are HTML encoded as `"`. In scripts the
programmer should use the safe filter, otherwise not.
This PR adds the tests by @msrd0 <git@msrd0.de> that failed before.
The error was fixed somewhen between f23162a and now, so these tests
serve to prevent regressions in the future.
I simplified the tests very slightly to omit whitespaces in the output.
`target()` as used in parsing "let" and "if let" implements parsing
nested tuples and structs. But it does not implement parsing literals.
The functions `match_variant()` and `with_parameters()` as used in
parsing "when" blocks do not implement parsing nested structs, but it
implements parsing literals.
This PR combines `match_variant()` and `with_parameters()` into
`target()`, so that all `{%when%}` support nested structs, too.
The current rust_test uses `stringify!()`. The documentation gives us
the warning:
> Note that the expanded results of the input tokens may change in the
> future. You should be careful if you rely on the output.
In the current nightly rust the result was indeed changed, so the test
not fails.
This PR replaces the test with another macro, that does not depend on
`stringify!()`.
Closes issue #504.
