Fixes #81

I decided to use pest to replace current custom parser for maintainability and correctness.

Tasks:

• [x] Grammar
• [x] Rebuild parser with pest Rdp.queue() results
• [x] Keeping error tracking: report template error with line/column number
• [x] Keeping template element maps, line/column number for each item
• [x] Retain leading whitespaces in text

I know this is probably just the beginning but I think I added a working markdown helper so that if you have a variable x that is a string containing markdown, then you can parse it to html by passing

{{markdown x}}

in the template..

I want to improve this by adding some kind of environment, but I couldn't quite figure it out right away (and the use case above is the one that i want to use anyway). As a second commit perhaps something like below could be implemented

{{#markdown}}
#wow
{{> sub_template}}
{{~markdown}}

edit: also sorry that this changed Cargo.toml so much. I used cargo add pulldown-cmark and it must have mangled the Cargo.toml I will go back and edit by hand

I just experienced a segfault which seems to be originated in the handlebars code.

As there are ~6000 stack levels, it seems that I ended up crashing into the heap by recursing too deep. The recursion seems to happen in handlebars, as only a few (as in below 10) stack levels are from my code.

The corrosponding code is here, here is the causing call.

The templates can be found here, the registration of the templates and the helpers is here. If you have any questions regarding the code, feel free to ask me, I know the codebase is pretty big and maybe confusing for some people.

To reproduce:

• Clone the repository, checkout the branch from the PR
• cargo build --manifest-path bin/core/imag-store/Cargo.toml # takes some time
• mkdir /tmp/store/
• ./target/debug/imag-store --rtp /tmp/ --config imagrc.toml create -p test entry -c foo
• enjoy.

The last few lines of the stacktrace follow

#6274 0x00005555556808c2 in core::result::Result<&handlebars::template::Template, handlebars::error::RenderError>::and_then<&handlebars::template::Template,handlebars::error::RenderError,(),closure> (self=Ok = {...}, op=closure = {...})
    at /build/rustc-1.17.0-src/src/libcore/result.rs:601
#6275 0x00005555555f8b18 in handlebars::registry::Registry::renderw<collections::btree::map::BTreeMap<&str, collections::string::String>> (self=0x7ffff6ab9038, name="DEBUG", data=0x7fffffff5578, writer=&mut Write)
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:247
#6276 0x00005555555f8654 in handlebars::registry::Registry::render<collections::btree::map::BTreeMap<&str, collections::string::String>> (self=0x7ffff6ab9038, name="DEBUG", data=0x7fffffff5578)
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:236
#6277 0x00005555556f75c4 in libimagrt::logger::{{impl}}::log (self=0x7ffff6ab9000, record=0x7fffffff5a50) at /home/m/archive/development/rust/imag/lib/core/libimagrt/src/logger.rs:149
#6278 0x0000555555e16a17 in log::__log (level=log::LogLevel::Debug, target="handlebars::render", loc=0x5555562f06a8 <<handlebars::template::TemplateElement as handlebars::render::Renderable>::render::_LOC>, args=Arguments = {...})
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.3.8/src/lib.rs:903
#6279 0x0000555555ae6784 in handlebars::render::{{impl}}::render (self=0x7ffff6a35400, registry=0x7ffff6ab9038, rc=0x7fffffff7038) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/render.rs:641
#6280 0x0000555555ae5e41 in handlebars::render::{{impl}}::render (self=0x7ffff6a37718, registry=0x7ffff6ab9038, rc=0x7fffffff7038) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/render.rs:590
#6281 0x00005555555f8f6e in handlebars::registry::{{impl}}::renderw::{{closure}}<collections::btree::map::BTreeMap<&str, collections::string::String>> (t=0x7ffff6a37718) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:254
#6282 0x00005555556808c2 in core::result::Result<&handlebars::template::Template, handlebars::error::RenderError>::and_then<&handlebars::template::Template,handlebars::error::RenderError,(),closure> (self=Ok = {...}, op=closure = {...})
    at /build/rustc-1.17.0-src/src/libcore/result.rs:601
#6283 0x00005555555f8b18 in handlebars::registry::Registry::renderw<collections::btree::map::BTreeMap<&str, collections::string::String>> (self=0x7ffff6ab9038, name="DEBUG", data=0x7fffffff79d8, writer=&mut Write)
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:247
#6284 0x00005555555f8654 in handlebars::registry::Registry::render<collections::btree::map::BTreeMap<&str, collections::string::String>> (self=0x7ffff6ab9038, name="DEBUG", data=0x7fffffff79d8)
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:236
#6285 0x00005555556f75c4 in libimagrt::logger::{{impl}}::log (self=0x7ffff6ab9000, record=0x7fffffff7eb0) at /home/m/archive/development/rust/imag/lib/core/libimagrt/src/logger.rs:149
#6286 0x0000555555e16a17 in log::__log (level=log::LogLevel::Debug, target="handlebars::render", loc=0x5555562f06a8 <<handlebars::template::TemplateElement as handlebars::render::Renderable>::render::_LOC>, args=Arguments = {...})
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.3.8/src/lib.rs:903
#6287 0x0000555555ae6784 in handlebars::render::{{impl}}::render (self=0x7ffff6a35400, registry=0x7ffff6ab9038, rc=0x7fffffff9498) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/render.rs:641
#6288 0x0000555555ae5e41 in handlebars::render::{{impl}}::render (self=0x7ffff6a37718, registry=0x7ffff6ab9038, rc=0x7fffffff9498) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/render.rs:590
#6289 0x00005555555f8f6e in handlebars::registry::{{impl}}::renderw::{{closure}}<collections::btree::map::BTreeMap<&str, collections::string::String>> (t=0x7ffff6a37718) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:254
#6290 0x00005555556808c2 in core::result::Result<&handlebars::template::Template, handlebars::error::RenderError>::and_then<&handlebars::template::Template,handlebars::error::RenderError,(),closure> (self=Ok = {...}, op=closure = {...})
    at /build/rustc-1.17.0-src/src/libcore/result.rs:601
#6291 0x00005555555f8b18 in handlebars::registry::Registry::renderw<collections::btree::map::BTreeMap<&str, collections::string::String>> (self=0x7ffff6ab9038, name="DEBUG", data=0x7fffffff9e38, writer=&mut Write)
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:247
---Type <return> to continue, or q <return> to quit---
#6292 0x00005555555f8654 in handlebars::registry::Registry::render<collections::btree::map::BTreeMap<&str, collections::string::String>> (self=0x7ffff6ab9038, name="DEBUG", data=0x7fffffff9e38)
    at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/handlebars-0.29.0/src/registry.rs:236
#6293 0x00005555556f75c4 in libimagrt::logger::{{impl}}::log (self=0x7ffff6ab9000, record=0x7fffffffa310) at /home/m/archive/development/rust/imag/lib/core/libimagrt/src/logger.rs:149

#6294 0x0000555555e16a17 in log::__log (level=log::LogLevel::Debug, target="libimagrt::runtime", loc=0x5555562e92f0 <libimagrt::runtime::Runtime::_new::_LOC>, args=Arguments = {...}) at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.3.8/src/lib.rs:903
#6295 0x00005555555d4d34 in libimagrt::runtime::Runtime::_new<clap::app::App> (cli_app=App = {...}, matches=ArgMatches = {...}, Python Exception <type 'exceptions.ValueError'> invalid literal for int() with base 0: '0x1 <error: Cannot access memory at address 0x1>': 
config=...) at <log macros>:7
#6296 0x00005555555d4319 in libimagrt::runtime::Runtime::new<clap::app::App> (cli_app=App = {...}) at /home/m/archive/development/rust/imag/lib/core/libimagrt/src/runtime.rs:97
#6297 0x00005555555d360d in libimagrt::setup::generate_runtime_setup<fn(clap::app::App) -> clap::app::App> (name="imag-store", version="0.4.0", about="Direct interface to the store. Use with great care!", builder=0x0)
    at /home/m/archive/development/rust/imag/lib/core/libimagrt/src/setup.rs:39
#6298 0x00005555555e642c in imag_store::main () at /home/m/archive/development/rust/imag/bin/core/imag-store/src/main.rs:71

This bumps the minimal acceptable versions in Cargo.toml to versions that are compatible with -Z minimal-versions. This is part of the process of seeing how hard this is for crates to use in preparation for getting it stabilized for use in CI, specifically upstreaming the changes required to get criterion working with it. It is easy to use if all of your dependencies support it, but much harder if trying to impose it on them.

Also cargo defaults to interpreting version requirements as ^. So this switched to the shorter form.

Rather than force every structure to implement the ToJson trait, it might be preferable to allow users to just add a #[derive(RustcEncodable)] on their structs, and handlebars can obtain a JSON value via the rustc_serialize::json::encode function.

Presumably because of #346 but haven't confirmed yet.

This custom helper https://github.com/CleverCloud/amq-protocol/blob/011ed7a80d4448b03ca2db48b50e73c03104b98d/codegen/src/templating.rs#L283-L343 now hits this assertion with 3.2.0 while it works fine with 3.1.0 https://github.com/CleverCloud/amq-protocol/blob/011ed7a80d4448b03ca2db48b50e73c03104b98d/codegen/src/templating.rs#L307

Test:

    #[test]
    fn test_template() {
        let mut handlebars = Handlebars::new();
        let data = json!({});
        handlebars.render_template("{{'test'}}", &data).unwrap();
    }

Throw,

---- test::test_template stdout ----
thread 'test::test_template' panicked at 'called `Result::unwrap()` on an `Err` value: RenderError { desc: "Failed to parse template.", template_name: None, line_no: None, column_no: None, cause: Some(TemplateError { reason: InvalidSyntax, template_name: None, line_no: Some(1), column_no: Some(3), segment: Some("   0 | {{'test'}}\n     |---^------\n") }), unimplemented: false }', src/main.rs:155:57
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Hi! I use the mdbook crate and it stopped compiling today, very likely due to handlebars' update.

I don't know much about both projects but here's the error:

Compiling mdbook v0.3.5
error[E0277]: `(dyn std::error::Error + 'static)` cannot be sent between threads safely
--> /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/mdbook-0.3.5/src/lib.rs:123:5
    |
123 | /     error_chain! {
124 | |         foreign_links {
125 | |             Io(std::io::Error) #[doc = "A wrapper around `std::io::Error`"];
126 | |             HandlebarsRender(handlebars::RenderError) #[doc = "Handlebars rendering failed"];
...   |
156 | |         }
157 | |     }
    | |_____^ `(dyn std::error::Error + 'static)` cannot be sent between threads safely
    |
    = help: the trait `std::marker::Send` is not implemented for `(dyn std::error::Error + 'static)`
    = note: required because of the requirements on the impl of `std::marker::Send` for `std::ptr::Unique<(dyn std::error::Error + 'static)>`
    = note: required because it appears within the type `std::boxed::Box<(dyn std::error::Error + 'static)>`
    = note: required because it appears within the type `std::option::Option<std::boxed::Box<(dyn std::error::Error + 'static)>>`
    = note: required because it appears within the type `handlebars::error::RenderError`
    = note: required because it appears within the type `errors::ErrorKind`
    = note: required because it appears within the type `errors::Error`
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

Since the update was a patch, the issue is more to report the breaking change than anything else.

Here's the issue in mdbook.

Hello! First off, thanks for all the great work!

I'm trying to render a Handlebars template that needs to iterate through a JSON object with keys that contain dots and spaces. This causes Handlebars to return a RenderError with description Invalid JSON path.

Minimal Example

It fails in the same way if I replace "strange key" with "strange.key". I tried this using handlebars-rust version 0.28.3.

extern crate handlebars;
#[macro_use]
extern crate serde_json;

use handlebars::Handlebars;

fn main() {
    Handlebars::new().template_render(
        "{{#each x}} {{@key}} {{this}}, {{/each}}",
        &json!({"x": {"a": 1, "b": 2, "strange key": 3}})
    ).map(|s| println!("{}", s)).unwrap();
}

Handlebars Code

I believe this line in src/grammar.rs in today's master branch is relevant:

path_ident = _{ ['a'..'z']|['A'..'Z']|['0'..'9']|["_"]|["@"]|["$"]|["<"]|[">"]|["-"]}

I'm unfamiliar with Handlebars, but this grammar could be updated to support more general JSON keys, or it could be ignored if referring to the key using this or @key.

I'd be glad to submit a PR if necessary, but I would appreciate any help.

Not sure if this is an issue with the library or my syntax. I'm updating a project that I wrote from the legacy partial syntax to the new syntax. I have three (simplified) templates like this:

<!-- base.hbs -->
<html>
<body>
{{> layout}}
</body>
</html>

<!-- blog.hbs -->
{{#> base}}

{{#*inline "layout"}}
<div>
{{#> content}}
Parent content
{{> otherHelper}}
{{/content}}
</div>
{{/inline}}

{{/base}}

<!-- blog_post.hbs -->
{{#> blog}}

{{#*inline "content"}}
Child content
{{/inline}}

{{/blog}}

The problem is that the otherHelper helper gets rendered (and output) twice, and I cannot figure out why.

If I had an enum like:

pub enum Value {
    Float(f64),
    Bool(bool),
}

How would I render something like:

{{#if value == Float(val)}}
    <input type='number' value={{val}} />
{{/if}}

{{#if value == Bool(val)}}
    <input type='checkbox' checked={{val}} />
{{/if}}

I can't figure out how to use square brackets to refer to a helper. While fuzzing, a template like {{[\0] ''}} failed and said there was no helper named \0 even though it was defined. However, when I used the same template and defined a helper named [\0], it worked.

Naming the helper \0 works in the Handlebars.js playground but naming it [\0] doesn't, so I'm not sure why the opposite is true for handlebars-rust.

Question

What am I doing wrong? I used handlebars.register_helper to register the helper. Is it supposed to be done some other way?

We need a web playground to demo and verify template or data. The playground should allow user to provide:

• a base template
• several partials with names
• data as json string
• helper defined as rhai script

The data gathered from user input is passed to web assembly module. The the result or error message is given back to user.

Web playground can be deployed to github pages via github action. We will always use latest master branch to built the wasm module.

Some benches were not totally stable on my computer (it's really hot these days, maybe I hit the temp freq switch of my cpu in the benches)

But on some case maybe black boxing and increasing the measurement (now 100 by default) is a start:

doc of criterion black_box: https://docs.rs/criterion/latest/criterion/fn.black_box.html

Fixes #157

This is an attempt in progress to add async support for handlebars helper. The whole render call stack needs to be async when any of the helper is async.

TODO Items:

• [ ] async helper registartion
• [ ] Registry APIs support for async helpers, like has_helper
• [ ] async render
• [ ] test and examples

In production code the helpers may returns error, we could returns the underlying error from helper when render_template.

Below are some pseudo-code:

fn query_name_by_id(id: &str) -> Result<String, DBError> {
	...
}

let result = hbr.render_template("The name is {{query_name_by_id this}}", &id);

match result {
	Ok() -> {},
	Err(e) -> {
		match e {
			Handlebars.Error(e) => // render error
			DBError(e) => // db error from query_name_by_id
			_ => {}
		}
	}
}