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"...
```
`normalize_identifier` is called quite often in the generator, once for
every variable name or path element that is written.
This PR aims to speed up the function by
* using a per-length input string length replacement map
* binary searching the replacement map instead of a linear search
Diffent, but functionally equivalent implementations were compared:
```text
* linear search in one big map: 348.44 µs
* binary search in one big map: 334.46 µs
* linear search in a per-length map: 178.84 µs
* binary search in a per-length map: 154.54 µs
* perfect hashing: 170.87 µs
```
The winner of this competition is "binary search in a per-length map".
It does not introduce new dependencies, but has the slight disadvantage
that it uses one instance of `unsafe` code. I deem this disadvantage
acceptable, though.
Nb. It was also tested if a variant that only stores the replaced string
would be faster. This "optimization" proved to be slower for all
implementations except "binary search in a per-length map", for which it
has the same runtime. Without a clear advantage to use the "optimized
version", I chose to use the more easy to read slice of tuples variant.
Obviously, for all measurements: YMMV.
