| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
268d825 introduced a regression that made matching against boolean
literals impossible. E.g. "true" was interpreted as the variable
"r#true". This PR fixes the problem.
The bug was reported by @Restioson in issue #531.
|
| |
|
| |
|
|
|
|
| |
Fixes using askama with the new Cargo feature resolver and a configuration file.
|
| |
|
|
|
|
|
|
|
| |
This web framework seems not to have been updated for quite a while,
and its current version appears to depend on vulnerable crates.
Remove it for now. If someone wants to fix up Iron upstream and
reinstate this, I'd be happy to review your PR.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Askama uses the syntax `{% when Variant with (parameters) %}` in
`{% match %}` blocks. This is done because Askama does not implement the
whole pattern matching of Rust's `match` statements.
This PR wants to bring Askama a step closer Rust's matching, so the
"with" keyword should not be needed anymore.
|
|
|
|
|
|
|
|
| |
Askama uses the syntax `{% when Variant with (parameters) %}` in
`{% match %}` blocks.
This change allows the optional use of the keyword "with" in "let" and
"if let" statements, too.
|
| |
|
|
|
|
|
| |
This PR implements the destructoring of structs on the lhs of "let" and
"for" statements.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This change also fixes a bug in the loop generator, which failed for
shadowed variables.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
By now only non-nested tuples are accepted by the parser, but this will
change. This change makes visit_target() call itself for items in a
tuple. So enable the function to call itself, I needed to fix the
lifetime annotation, because the references inside a Target instance may
outlife a reference to instance itself.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
rust-lang/rust#82069 made error message that stem macro invocations more
verbose. Since Rust 1.54 (currently in beta) the message includes the
name of the offending macro.
This PR uses version_check to select the appropriate expected error
message.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
See #412 for earlier iteration.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was based off of the OWASP XSS prevention cheat sheet --
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary
However, there isn't really any attack vector based on forward slash alone, and
it's being removed in the next version of that document.
> There is no proof that escaping forward slash will improve
> defense against XSS, if all other special characters are escaped
> properly, but it forces developers to use non-standard implementation of
> the HTML escaping, what increases the risk of the mistake and makes the
> implementation harder.
https://github.com/OWASP/CheatSheetSeries/pull/516
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Co-authored-by: Daniel Arbuckle <djarb@highenergymagic.org>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|