| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
|  | 
The configuration is made `'static`, because `toml` and `toml_edit` both
needs to implement serde's `DeserializeOwned` by now. We allocate the
strings once per template, so it is very unlikely that this change will
have any measurable impact, neither in compile time nor RAM usage.
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This PR makes e.g. `{% leta = b %}` a parsing error. To the reader it
would appear that `leta` should be a meaningful expression in Askama,
which it is not. Before this PR, `leta` was tokenized as `let` + `a`.
This PR makes the parser try to find the longest identifier at a parsing
positions and only compare the outcome against the expected keyword.
This is potentially a breaking change, because code that should always
have been invalid will now fail to compile, when it was accepted before.
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
|  | 
That part was missing from #632, because #632 came before #706, and I
forgot to update the older PR.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
|  | 
The support for the magic `_parent` field is deprecated since v0.8.0
or issue #180. It's bothersome to keep this feature alive, when no-one
should be using it for 3 years.
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The integration is based on askama_gotham.
There is no specific trait to convert an arbitrary T to
`hyper::Response`, so I used `From<Template> for hyper::Response`.
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Though Rocket 0.5 still only a release candidate, Rocket 0.4 severely
outdated, and depends on a bunch of crates with active security
advisories. Rocket 0.5 updates its dependencies to fixes versions.
Also Rocket 0.4 needs a nightly Rust, which caused multiple problems.
 | 
| | 
| 
|  | 
No need to work on references to references.
 | 
| |  | 
 | 
| | 
| 
| 
| 
|  | 
The generator cannot be accessed outside of crate, so it's not possible
to override the default hasher.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
|  | 
* Moved Features into derive, Updated Askama versions to 0.11
* Lock minimal versions to 0.11.2
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
All the hard work in askama_derive was actually done in askama_shared.
This PR removes the back-and-forth interaction between the two crates.
Now askama_derive is a single re-export of `#[derive(Template)]` which
has to be done in a proc_macro crate.
This most likely means that askama_derive is "final", unless another
derive template needs to be introduced in the future.
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Before this PR the handling of integrations was done both by
askama_shared and askama_derive. This diff lets askama_shared do the
work. This will prevent problems like #629, when both packages might
come out of sync.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
|  | 
PathBuf is to String like Path is to str, so `&PathBuf` is a pointer to
a pointer. Clippy does not likes that.
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Issue #527 removed the askama_iron package, but not the integration if
someone uses askama_derive's feature with "iron".
The old askama_iron crate uses askama v0.10, so it will still work.
 | 
| |  | 
 | 
| |  | 
 | 
| |\  
| | 
| |  | 
Prepare 0.12
 | 
| | |  | 
 | 
| | |  | 
 | 
| |/   | 
 | 
| |  | 
 | 
| |  | 
 | 
| | 
| 
| 
|  | 
Fixes using askama with the new Cargo feature resolver and a configuration file.
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 | 
| |  | 
 |