This PR was merged into the 1.x branch.
Discussion
----------
Fix GlobalsInterface extends for IDE
Commits
-------
0b819abb Fix GlobalsInterface extends for IDE
This PR was merged into the 1.x branch.
Discussion
----------
Use isset before array_key_exists
Small performance improvment when using
```
{% set foo = foo|default("bar") %}
```
Will render the following code
```
$context["foo"] = (((isset($context["foo"]) || array_key_exists("foo", $context))) ? (_twig_default_filter((isset($context["foo"]) || array_key_exists("foo", $context) ? $context["foo"] : (function () { throw new Twig_Error_Runtime('Variable "foo" does not exist.', 1, $this->source); })()), "bar")) : ("bar"));
```
instead of
```
$context["foo"] = ((array_key_exists("foo", $context)) ? (_twig_default_filter((isset($context["foo"]) || array_key_exists("foo", $context) ? $context["foo"] : (function () { throw new Twig_Error_Runtime('Variable "foo" does not exist.', 1, $this->source); })()), "bar")) : ("bar"));
```
Commits
-------
230d3412 Use isset before array_key_exists
This PR was merged into the 2.x branch.
Discussion
----------
Fix the error handling for the optimized extension-based function calls
Triggering a Twig_Error_Runtime at compile-time breaks the contract of the Twig environment, as such exception is for errors during the rendering.
This moves back the exception to a runtime one (same behavior than before the optimization).
Another option would be to replace this with a `Twig_Error_Syntax` instead (reporting the error earlier), but that would change the exception being thrown for such case.
Commits
-------
9928ae14 Fix the error handling for the optimized extension-based function calls
This PR was merged into the 2.x branch.
Discussion
----------
Report the proper location for errors compiled in templates
The `{% use %}` and `{% with %}` tags are adding some runtime checks triggering exceptions in the compiled template. This ensures that they get the proper location.
While the guessing was generally working fine for the `{% with %}` (and so this only makes the code faster), the guessing was not working for `{% use %}` due to the exception happening in the class constructor rather than on display (and so the guessing was finding the template which was triggering the load of the faulty template).
Commits
-------
e4423576 Report the proper location for errors compiled in templates
This PR was merged into the 1.x branch.
Discussion
----------
Ensure that syntax errors are triggered with the right line
When throwing the syntax error without any line and source in these places, the guessing logic enters into action. For the main template, it won't find anything. But for included templates (or any other template loaded during the rendering of another one, even as main one), the guessing will find a template (the caller one) and set the source and line based on it. The source will then be replaced by the proper template by `\Twig_Environment::compileSource`, but the guessed line number will make no sense then.
I searched for all places triggering a syntax error in Twig, to ensure that they always set the actual line number or set the source directly (so that the guessing logic knows that the template it found is the wrong one and so does not try to use it for guessing). There were only a few missing ones.
Commits
-------
6fab6b0b Ensure that syntax errors are triggered with the right line
The {% use %} and {% with %} tags are adding some runtime checks triggering
exceptions in the compiled template. This ensures that they get the proper
location.
While the guessing was generally working fine for the {% with %} (and so this
only makes the code faster), the guessing was not working for {% use %} due
to the exception happening in the class constructor rather than on display
(and so the guessing was finding the template which was triggering the load
of the faulty template).
This PR was merged into the 2.x branch.
Discussion
----------
Deprecate using the spaceless tag at the root level of a child template (noop anyway)
~~WIP as I'd like to trigger a deprecation notice (which will only be possible with some other changes coming up in another PR) and add some tests for the deprecated behavior.~~
Commits
-------
b2dac7df deprecated using the spaceless tag at the root level of a child template (noop anyway)
This PR was merged into the 2.x branch.
Discussion
----------
Deprecate the possibility to define a block in a non-capturing block from a child template
fixes#351, #541, #703, #988, #1639, #1685, #2393
One recurring issue (see the probably non-exhaustive list of issues references above) is a misunderstanding of how blocks work in a child template.
For instance, there is no way to define a `block` conditionally:
```twig
{% extends "layout" %}
{% if ... %}
{% block content %}
...
{% endblock %}
{% endif %}
```
And wrapping a `block` definition with a `spaceless` tag does not work:
```twig
{% extends "layout" %}
{% spaceless %}
{% block content %}
...
{% endblock %}
{% endspaceless %}
```
The issue is that the above templates compile just fine, but not in a way people expect. Basically, the condition would be empty.
Interestingly enough, wrapping a `block` definition might be useful/work as expected when used with "capturing" tags like `set`:
```twig
{% extends "layout" %}
{% set content %}
{% block content %}
...
{% endblock %}
{% endset %}
```
Not sure if that's useful, but here, the `block` tag will serve as the blog definition AND it will also be displayed in place. I would not recommend such usages.
This pull request deprecates the cases where the compiled template would never reflect the developer intent, but keeps the "working" scenarii as is.
I've been trying to fix that issue for **years**. Very happy to have found a simple solution without breaking anything that worked fine.
Commits
-------
9b938887 deprecated the possibility to define a block in a non-capturing block from a child template
This PR was merged into the 2.x branch.
Discussion
----------
Move legacy tests that were not executed anymore in 2.x
While working on some new deprecations, I noticed that some fixtures were in a directory that was not used anymore in 2.x. I've moved the relevant one back to the main Fixtures directory and remove the other one, which is not relevant anymore.
Commits
-------
c412d0f4 moved legacy tests that were not executed anymore in 2.x
This PR was merged into the 1.x branch.
Discussion
----------
Fixed PHPDoc of Twig_Token::test
For exemple `Twig_TokenParser_Set` use `->test('endset')`
Commits
-------
35a1070a Fixed PHPDoc of Twig_Token::test
This PR was merged into the 1.x branch.
Discussion
----------
Add the Symfony ctype polyfill as a dependency
Commits
-------
5b9a70b3 added the Symfony ctype polyfill as a dependency
Fabien Potencier
Maxime Steinhausser
Yonel Ceruto
Jérémy Derussé
Christophe Coevoet
Christian Flothmann
Fabien Potencier
Grégoire Pineau
ismael-miguel