Fixed implicit borrow of expressions

[vallentin]

This does not introduce any breaking changes^*.

The change fixes so expressions are now borrowed as a whole, instead of only the first value. Which would cause compile errors, for types that don't implement e.g. Add<T> for &T.

In short expressions now expand into &(...) instead of &....

^* Technically, it would be considered a breaking change. However, I'd say it's highly unlikely someone has implemented e.g. Add<T> for &T and not Add<T> for T. To be able to rely on something that could be considered inconsistent behavior.

---

Example 1

Minimal example:

{{ true && true }}

Which expands like this:

Before: &true && true
After: &(true && true)

Resulting in the following compile error:

error[E0308]: mismatched types
   |
11 | #[derive(Template)]
   |          ^^^^^^^^ expected `bool`, found `&bool`

This isn't and was never an issue for e.g. {{ 1 + 2 }}, as the various operators e.g. Add<&T> for T are implemented for various types. However, this is not the case for short-circuit operators.

To have a more complete example of when this applies. I personally have a few macros, which accept booleans to decide on what it expands to.

{% macro foo(b) %}
    {% if b.clone() %}
        ...
    {% endif %}
{% endmacro %}

{% call foo(true && true) %}

Which expands like this:

Before: let (b) = (&true && true);
After: let (b) = (&(true && true));

The fact that .clone() is needed, is a whole other can of worms.

---

Example 2

Another example where this also manifests itself is:

#[derive(Template)]
#[template(path = "foo.html.jinja")]
struct Foo {
    time: SystemTime,
    dur: Duration,
}

{{ self.time + self.dur }}

Once again only Add<Duration> for SystemTime exists, so this also resulted in a compile error:

error[E0369]: cannot add `Duration` to `&SystemTime`

[djc]

LGTM, thanks!