Text within {% raw %} is being jumbled when it contains multiple liquid variables

[epage]

The cobalt website has this line:
{% raw %} <a href="{{post.path}}">{{ post.title }}</a>{% endraw %}
See https://github.com/cobalt-org/cobalt-org.github.io/blob/source/docs/pages.liquid#L78

That is being rendered as
</a>{{ post.title }}">{{post.path}} <a href="
See https://github.com/cobalt-org/cobalt-org.github.io/blob/master/docs/pages.html#L110

[booyaa]

I was about to file a bug when I found this issue. It's reversing the order of the escaped items.

test code

use liquid::{Renderable, Context, Value};

let template = liquid::parse(
r"{% raw %}
{{ abc }}
{{ def }}
{{ ghi }}
{% endraw %}", Default::default()).unwrap();

let mut context = Context::new();
context.set_val("num", Value::Num(4f32));

let output = template.render(&mut context);
assert_eq!(output.unwrap(), Some("\n{{ abc }}\n{{ def }}\n{{ ghi }}\n".to_string()));

I'm going to have a go a see if I can fix it!

[booyaa]

I'm getting a bit confused, I thought this was a fault with the raw block, but my latest findings would indicate otherwise.

I jumped straight into the raw block code and added a new test that should fail.

#[test]
fn test_raw_ordered() {
    use std::default::Default;

    let options: LiquidOptions = Default::default();
    let raw = raw_block("raw",
                        &[],
                        &vec![Expression(vec![], "{{abc}}\n{{def}}\n{{ghi}}".to_owned())],
                        &options);
    assert_eq!(raw.unwrap().render(&mut Default::default()).unwrap(),
               Some("{{abc}}\n{{def}}\n{{ghi}}".to_owned()));
}

It didn't fail, it passed!

Yet my test code still fails. I've cleaned up the code from last update.

fn main() {
    use liquid::Renderable;

    let template = liquid::parse(r"{% raw %}
{{ abc }}
{{ def }}
{{ ghi }}
{% endraw %}", Default::default()).unwrap();

    let output = template.render(&mut Default::default());
    assert_eq!(output.unwrap(),
               Some("\n{{ abc }}\n{{ def }}\n{{ ghi }}\n".to_string()));
}

Wondering I should look next? I'm thinking the parser or render calls?