Upgrade problem

bumped version to 1.12.0-DEV

prepared the 1.12.0-RC1 release

fixed typo in the docs

fixed wrong version in the docs

merged branch fabpot/performance-fix (PR #941)

This PR was merged into the master branch.

Commits
-------

2450f79 changed the way globals behave to be more BC with 1.11 and to avoid speed problems at runtime introduced in 4487387 (closes #932)

Discussion
----------

changed the way globals behave to be more BC with 1.11 and to avoid speed problems at runtime introduced in 4487387 (closes #932)

* Globals are now managed by themselves, independently of other elements
  contained in extensions

* A global variable value can now be changed after the runtime has been
  initialized (to be more BC with the way Twig 1.11 works)

* Extensions are not initialized anymore when rendering a template that
  is already in the cache (like in Twig 1.11)

removed PEAR related code

changed the way globals behave to be more BC with 1.11 and to avoid speed problems at runtime introduced in 4487387 (closes #932)

* Globals are now managed by themselves, independently of other elements
  contained in extensions

* A global variable value can now be changed after the runtime has been
  initialized (to be more BC with the way Twig 1.11 works)

* Extensions are not initialized anymore when rendering a template that
  is already in the cache (like in Twig 1.11)

merged branch fabpot/render-function (PR #926)

This PR was merged into the master branch.

Commits
-------

f4f88a5 added an include function

Discussion
----------

added an include function

---------------------------------------------------------------------------

by stof at 2012-12-09T14:12:25Z

I see an issue with this naming: it will confuse Symfony users because of the ``render`` tag doing something different than the ``render`` function. And it will force to break BC for Silex users where the subrequest logic is using a ``render`` function right now

---------------------------------------------------------------------------

by fabpot at 2012-12-10T12:49:57Z

@stof: I know about the possible confusion. For Silex, as it is not stable yet, we don't need to keep BC. And I don't have any other better name. What I want to introduce next is a `render_request` function in both Silex and Symfony (which will do the same as the current render tag in Symfony and the render function in Silex).

---------------------------------------------------------------------------

by Taluu at 2012-12-10T14:13:31Z

Hi,

I may be absent-minded, but I don't really understand the difference between `render` function and the `include` tag... ?

---------------------------------------------------------------------------

by fabpot at 2012-12-10T14:16:09Z

@Taluu Using a function allows you to do whatever you want with the output (which is not possible with a tag), like a simple:

```jinja
{{ set content = render('some_template') }}
```

Also, semantically, using a tag to output some content is less correct.

---------------------------------------------------------------------------

by vicb at 2012-12-10T14:18:17Z

could it be named `include` ?

---------------------------------------------------------------------------

by tcz at 2012-12-10T14:18:40Z

I agree that it's confusing for Symfony users. It is the same as raw filter and raw tag. I would prefer execute as name or something like that

---------------------------------------------------------------------------

by Taluu at 2012-12-10T14:19:29Z

@fabpot so, does it means that it could replace the include tag ? Then, we could could name it `include` as @vicb suggested... ?

---------------------------------------------------------------------------

by titomiguelcosta at 2012-12-10T14:21:51Z

I agree with @stof, naming it render will be confusing, parse or execute or compile are other names that come to my mind for this purpose.

---------------------------------------------------------------------------

by silentworks at 2012-12-10T14:24:36Z

How about calling it `partial`? even though you are rendering a full template, it is being included in another so this could be seeing as a partial of that template.

---------------------------------------------------------------------------

by stof at 2012-12-10T14:26:05Z

@titomiguelcosta parse is totally wrong. The function is not parsing the string you give it. you don't pass the content of the template but its name. and ``compile`` is also wrong. It is not compiling a template but rendering it.

---------------------------------------------------------------------------

by jmather at 2012-12-10T14:30:53Z

I think `render` is probably the most appropriate name, but also may cause confusion, however I don't have another suggestion that is nearly as clear as to context and meaning.

---------------------------------------------------------------------------

by emgiezet at 2012-12-10T14:31:26Z

Can you pass the array of params as an argument to the `render` function?

---------------------------------------------------------------------------

by titomiguelcosta at 2012-12-10T14:31:59Z

@stof true that we pass the filename as argument, but we end up parsing the file.

---------------------------------------------------------------------------

by stof at 2012-12-10T14:32:48Z

@emgiezet you mean passing some variables available in the included template ? Sure you can. See the doc. the argument is named ``variables``

---------------------------------------------------------------------------

by stof at 2012-12-10T14:34:36Z

@titomiguelcosta But the goal of the function is not to parse the file (btw, it may not parse it if the template was already compiled in the cache). The goal is to render the template.

Btw, I agree with @jmather. As far as Twig is concerned, ``render`` is the best name. The only issue comes from the fact that Symfony already use a ``{% render %}`` tag with a different meaning

---------------------------------------------------------------------------

by emgiezet at 2012-12-10T14:39:02Z

@stof thx a lot didn't noticed the doc link. Maybe `render_partial` will be good in this case?

---------------------------------------------------------------------------

by tcz at 2012-12-10T14:44:13Z

In an ideal world the Symfony2 `render` tag would be renamed to `subrequest` or something like that and the new function in Twig would get the `render` name. The question is how many people use Twig because of Symfony2 and how many of them use it in itself (in my company we use standalone Twig for example).

I think it's important to avoid `raw`-style confusions for the former group.

---------------------------------------------------------------------------

by stof at 2012-12-10T15:16:28Z

@tcz The issue with renaming the tag in Symfony is that it would be a BC break. So we cannot simply drop the tag (we can provide a new name and deprecate the current one, but we would still keep it).

---------------------------------------------------------------------------

by Taluu at 2012-12-10T15:18:56Z

I think `partial` would be a good idea... But still, does it mean that the `include` tag would be deprecated in favor of `render` (or whatever the name will be) function ?

---------------------------------------------------------------------------

by tcz at 2012-12-10T15:19:49Z

@stof Yes :( hence my remark "in an ideal world"

---------------------------------------------------------------------------

by stof at 2012-12-10T15:27:52Z

@Taluu It depends if @fabpot wants to keep the compatibility with Jinja where possible (as it is where the ``include`` tag comes from)

---------------------------------------------------------------------------

by WouterJ at 2012-12-10T15:48:26Z

I like the function, but I don't like the name. I like the name `partial`.

I am a front-end developer from origin and all files you include in the base CSS stylesheet are called 'partials' in SASS or other preprosessors. Twig is used to make live easier for front-end developers and I think a function called `partial` is more familiair for them than `render`.

---------------------------------------------------------------------------

by silentworks at 2012-12-10T16:17:24Z

@stof I guess based on @fabpot wanting to keep Twig compatibility with Jinja, calling the tag `partial` rather than `render` shouldn't be a problem since Jinja doesn't have any of these.

---------------------------------------------------------------------------

by Taluu at 2012-12-10T16:19:25Z

@silentworks @stof was talking about my question, about why keep the `include` tag if the `render` (or whatever the name will be) is indeed inserted into Twig. :)

---------------------------------------------------------------------------

by stof at 2012-12-10T16:19:38Z

@silentworks I was not talking about the name of the function, but about the removal of the ``include`` tag

---------------------------------------------------------------------------

by silentworks at 2012-12-10T16:22:37Z

Thanks for clarity from both.

On the basis of keeping to conformity to Jinja, should this function not be a part of twig extensions rather than in the core?

---------------------------------------------------------------------------

by mvrhov at 2012-12-10T17:20:03Z

Well search and replace for symfony users when upgrading shouldn't be that hard so I'd say that we rename the symfony block into subrequest or sth similar.

---------------------------------------------------------------------------

by Taluu at 2012-12-10T17:26:22Z

If we were to follow your recommandations, we could say the same for all and every changes inducing a BC break huh...

---------------------------------------------------------------------------

by markstory at 2012-12-10T17:49:36Z

What about naming the function `include`?  It would share a name with the tag, but it also does the same type of thing as the tag.  The function has the advantage of having its return captured.  I think  `{{ include(template) }}` semantically does what it looks like it does when operating on the template object as well.

Other names that I think could fit well are `partial` and `display`. Render works well, but I understand people not wanting to overlap with existing symfony features that do very different things.

---------------------------------------------------------------------------

by Baachi at 2012-12-10T18:13:25Z

I think "partial" is a better name for this function and it would keep BC.

merged branch Baachi/fix-simple (PR #939)

This PR was merged into the master branch.

Commits
-------

a311fe0 Fix the registration of simple filters, test and functions

Discussion
----------

Fix the registration of simple filters, test and functions

Hey!

This PR fix the registration of `Twig_SimpleFilter`, `Twig_SimpleFunction` and `Twig_SimpleTest`.
See issue #937

Fix the registration of simple filters, test and functions

added an include function

added emacs in the IDE support section of the docs

fixed small typo in the docs

fixed regression

merged branch fabpot/callables-everywhere (PR #905)

This PR was merged into the master branch.

Commits
-------

1918ede added the ability to use any PHP callable to define filters, functions, and tests

Discussion
----------

added the ability to use any PHP callable to define filters, functions, and tests

Everything is in the title.

---------------------------------------------------------------------------

by Tobion at 2012-11-18T13:25:51Z

Are filters etc. slower when defined as closures (instead of function definitions)?

---------------------------------------------------------------------------

by fabpot at 2012-11-18T13:30:47Z

@Tobion No, it does not matter how they are defined. Speed will be the same. A function is probably slightly faster as we can optimize the compiled template more than when it is an anonymous function where we need to use `call_user_func`.

---------------------------------------------------------------------------

by Tobion at 2012-11-18T13:40:17Z

This slight difference is what I questioned. On top of that, PHP can also not precompile those `call_user_func` I guess (e.g. when using APC). But it's probably not a big deal.
Since you have many examples in the doc with closures, I hope that it does not become the standard way for people to define custom functions.

merged branch fabpot/loop-errors (PR #927)

This PR was merged into the master branch.

Commits
-------

811dfad added a syntax error when using a loop variable that is not defined (closes #925)
aa15cae simplified code

Discussion
----------

added a syntax error when using a loop variable that is not defined

refs #925

---------------------------------------------------------------------------

by stof at 2012-12-10T15:18:30Z

in the ifexpr, you should also check for ``loop.index`` & co as they are not yet incremented (and so cannot be used properly)

---------------------------------------------------------------------------

by fabpot at 2012-12-10T20:07:08Z

@stof fixed

added a syntax error when using a loop variable that is not defined (closes #925)

simplified code

added @deprecated tags on deprecated classes

added the ability to use any PHP callable to define filters, functions, and tests

added Twig_TemplateInterface in the list of deprecated interfaces

added a note about deprecated interfaces

added a note about the PEAR package

moved some code to the proper location

added an exception when misusing macro calls (refs #922)

merged branch javiereguiluz/master (PR #923)

This PR was merged into the master branch.

Commits
-------

33539fc Fixed a typo in the 'escape' filter documentation.

Discussion
----------

Fixed a typo in the 'escape' filter documentation.

This typo prevents the proper rendering of one code block.

Fixed a typo in the 'escape' filter documentation.

This typo prevents the proper rendering of one code block.

merged branch fabpot/twig-c-bug (PR #920)

This PR was merged into the master branch.

Commits
-------

df13370 added a missing test
33e690b fixed some tests when the extension is not enabled
51e707f merged branch char101/fix-ext-retval (PR #921)
014f459 added some missing test for Template::getAttribute()
e8d12da Fix empty string comparison
4311df3 added some missing test for Template::getAttribute()

Discussion
----------

The C extension does not behave in the same way as the PHP code

The added test shows that the C extension does not behave in the same way as the PHP code. I have no idea why. The problem is probably around line 1033 in the extension code: https://github.com/fabpot/Twig/blob/master/ext/twig/twig.c#L1033

---------------------------------------------------------------------------

by stof at 2012-12-05T17:07:00Z

The testsuite is broken when you run it without the C Twig extension. The test should be skipped when ``useExt`` is ``true`` and the extension is not available

added a missing test

fixed some tests when the extension is not enabled

merged branch char101/fix-ext-retval (PR #921)

This PR was merged into the twig-c-bug branch.

Commits
-------

e8d12da Fix empty string comparison
4311df3 added some missing test for Template::getAttribute()

Discussion
----------

Fix empty string comparison

Issue #920

added some missing test for Template::getAttribute()

Fix empty string comparison

added some missing test for Template::getAttribute()

removed uneeded condition (a filter node cannot be created if the filer does not exist)

added missing tests for sandbox support in Template::getAttribute()

added some missing tests for getAttribute (for isXXX methods)

merged branch fabpot/extension-registration (PR #917)

This PR was merged into the master branch.

Commits
-------

4487387 reverted the early registration of extensions (extensions are now loaded as before -- as late as possible) -- closes #910

Discussion
----------

reverted the early registration of extensions (extensions are now loaded as before -- as late as possible)

---------------------------------------------------------------------------

by stof at 2012-11-30T20:18:51Z

Looks good to me

reverted the early registration of extensions (extensions are now loaded as before -- as late as possible) -- closes #910

fixed typo

added some unit for previous merge

merged branch arthens/master (PR #916)

This PR was merged into the master branch.

Commits
-------

16dc94e Fix broken variable reference

Discussion
----------

Fix broken variable reference

The exception message is referencing a non-existing variable $token, renamed to $tokens.

Fix broken variable reference

merged branch LouTerrailloune/patch-1 (PR #913)

This PR was merged into the master branch.

Commits
-------

c3281bb Update doc/filters/split.rst

Discussion
----------

Update doc/filters/split.rst

Added missing quotes in return values.

---------------------------------------------------------------------------

by sstok at 2012-11-23T09:17:35Z

:+1:

merged branch catchamonkey/compiler_typo (PR #915)

This PR was merged into the master branch.

Commits
-------

ae73c4c Fixes a typo in the compiler outdent comment

Discussion
----------

Fixes a typo in the compiler outdent comment

Embarrassing really as I introduced the typo back in June.

---------------------------------------------------------------------------

by catchamonkey at 2012-11-23T13:07:58Z

Failed due to time out, I can't rerun though as I', not part of this repo.
@fabpot could you rerun or merge anyway as it's a comment change?

---------------------------------------------------------------------------

by sstok at 2012-11-25T11:56:36Z

:+1:

Fixes a typo in the compiler outdent comment

Update doc/filters/split.rst

Added missing quotes in return values.

merged branch Tobion/refactor-core-ext (PR #907)

This PR was merged into the master branch.

Commits
-------

6deee76 refactor test_empty and in_filter

Discussion
----------

refactor test_empty and in_filter

merged branch gunnarlium/master (PR #908)

This PR was merged into the master branch.

Commits
-------

a666505 Update doc for consistency.

Discussion
----------

docs: Use lipsum in all examples.

Fixes a small inconsistency in the docs for extending twig.

merged branch Tobion/editorconfig (PR #909)

This PR was merged into the master branch.

Commits
-------

e8ee79f added editorconfig file

Discussion
----------

added editorconfig file

This file is also in symfony. So also having it in twig would make things easier and consistent.

added editorconfig file

Update doc for consistency.

refactor test_empty and in_filter

merged branch fabpot/env-simplifications (PR #904)

This PR was merged into the master branch.

Commits
-------

0a7b37b changed the way extension filters/tests/functions/node visitors/globals/token parsers are registered (they were loaded as late as possible, they are now loaded as early as possible)

Discussion
----------

simplified some code

This PR changes the way extension filters/tests/functions/node visitors/globals/token parsers are registered (they were loaded as late as possible, they are now loaded as early as possible)

It mainly consists of a code cleanup by removing the horrible staging hack we have now.

changed the way extension filters/tests/functions/node visitors/globals/token parsers are registered (they were loaded as late as possible, they are now loaded as early as possible)

tweaked documentation

fixed 5.2 compat

merged branch fabpot/tokenparserbroker (PR #903)

This PR was merged into the master branch.

Commits
-------

8563e04 deprecated the token parser broker sub-system

Discussion
----------

deprecated the token parser broker sub-system

This is the first of a series of PRs where I want to deprecate some features that made sense at some point but do not anymore or features that are barely used. Deprecated features will still work in all versions of Twig 1.x but they will be removed in Twig 2.0.

This first one should not be controversial. The token parser broker was added at a time where functions in Twig were not available. Nowadays, creating a new tag is so rare that I cannot see any usage for the broker system.

As far as I know, nobody uses the broker system anyway (this feature is not even documented), except [Zwig](https://github.com/arnaud-lb/Zwig). And Zwig should probably create functions instead of tags for ZF helpers anyways.

ping @arnaud-lb

---------------------------------------------------------------------------

by arnaud-lb at 2012-11-16T17:27:02Z

IIRC the main reason for using this in Zwig was that ZF makes it hard to list helpers, and easy to get an helper by name. So the broken allows to use ZF helpers without listing them. The reason for using tags instead of functions is that many helpers in ZF are not used for their return value and/or printing. (Zwig also exposes helpers as functions, through registerUndefinedFunctionCallback, for those used for their return value or printing.)

No objection for removing in 2.x though.

deprecated the token parser broker sub-system

merged branch fabpot/named-arguments (PR #901)

This PR was merged into the master branch.

Commits
-------

4647913 added the ability to set default values for macro arguments (closes #447)
a59dcde added support for named arguments for filters, tests, and functions
65637b7 refactored the code handling arguments for PHP callbacks when compiling nodes

Discussion
----------

Named arguments and macro default values

This PR contains two new features. Even if they are not related, the code needed to make them work was almost the same.

The first feature is the ability to use named arguments for functions, tests, and filters:

```jinja
    {{ data|convert_encoding('UTF-8', 'iso-2022-jp') }}

    {# versus #}

    {{ data|convert_encoding(from='iso-2022-jp', to='UTF-8') }}
```

The syntax is borrowed from Python where named arguments are part of the language.

The second feature is the ability to defined default values for macro arguments:

```jinja
    {% macro input(name, value = "", type = "text", size = 20) %}
        <input type="{{ type }}" name="{{ name }}" value="{{ value|e }}" size="{{ size }}" />
    {% endmacro %}

```

More information in the updated documentation.

These features have been implemented with BC in mind (which means that the code is not optimal, but it will be completely refactored for Twig 2.0 where we will get rid of all those ridiculous `Twig_Filter_*` and `Twig_Function_*` classes).

---------------------------------------------------------------------------

by fabpot at 2012-11-15T10:34:16Z

I forgot to mention that there is no overhead if you are not using these new features, and that the overhead is only at compilation time (the compiled templates are the same as before).

---------------------------------------------------------------------------

by marekkalnik at 2012-11-15T10:36:49Z

That are some great features, thanks ! :+1:

---------------------------------------------------------------------------

by lolautruche at 2012-11-15T10:46:42Z

Nice ! :+1:
@fabpot So I guess the old behavior is kept, isn't it ?

---------------------------------------------------------------------------

by fspillner at 2012-11-15T10:50:31Z

Awesome!

---------------------------------------------------------------------------

by fabpot at 2012-11-15T11:28:20Z

@lolautruche yes, the old way still works of course.

---------------------------------------------------------------------------

by Seldaek at 2012-11-15T11:42:40Z

Awesome! This has been much needed a few times in the past. We can almost drop php altogether and just write twig :P

---------------------------------------------------------------------------

by marfillaster at 2012-11-15T12:07:43Z

@Seldaek maybe a twig to php processor

---------------------------------------------------------------------------

by Seldaek at 2012-11-15T12:14:34Z

@marfillaster that's already what twig is :)

---------------------------------------------------------------------------

by Tobion at 2012-11-15T12:38:28Z

@fabpot nice stuff

---------------------------------------------------------------------------

by simensen at 2012-11-15T16:01:03Z

This looks great!

---------------------------------------------------------------------------

by sstok at 2012-11-15T19:18:53Z

This was basically the only thing missing I was missing in Twig
:100: :+1:

---------------------------------------------------------------------------

by jorgelbg at 2012-11-15T20:05:15Z

I love this new feauture, it's great to have this on Twig! Brings a lot of clarity to my future templates ;-)

added the ability to set default values for macro arguments (closes #447)

added support for named arguments for filters, tests, and functions

refactored the code handling arguments for PHP callbacks when compiling nodes

moved filters/functions/tests syntax errors to the parser

switched version to 1.12

added support for extended ternary operator syntaxes (closes #134)

bumped version to 1.11.2-DEV

prepared the 1.11.1 release

tweaked previous merge (refs #894)

merged branch char101/fix-debug-lineno (PR #894)

This PR was squashed before being merged into the master branch (closes #894).

Commits
-------

7c5854b Fix twig error lineno off by 2

Discussion
----------

Fix twig error lineno off by 2

It seems to me that the lineno reported by Twig_Error is off by 2 from the real lineno in the generated PHP source

For example:

```
{% if true %}
Yes
{% endif %}
```

```php
<?php

/*  */
class __TwigTemplate_d41d8cd98f00b204e9800998ecf8427e extends Twig_Template
{
    public function __construct(Twig_Environment $env)
    {
        parent::__construct($env);

        $this->parent = false;

        $this->blocks = array(
        );
    }

    protected function doDisplay(array $context, array $blocks = array())
    {
        // line 1
        if (true) { // <- this is line 19
            // line 2
            echo "Yes // <- this is line 21
";
        }
    }

    public function getTemplateName()
    {
        return null;
    }

    public function isTraitable()
    {
        return false;
    }

    public function getDebugInfo()
    {
        return array (  19 => 2,  17 => 1,); // <- should be return array (  21 => 2,  19 => 1,);
    }
}
```

---------------------------------------------------------------------------

by char101 at 2012-11-08T08:23:57Z

Since `$compiler->addDebugInfo()` is called first before writing the node content, usually the number of lines in the PHP code is less than 2 (1 for the // lineno comment, and 1 for the generated content) than the line where the node content is written.

Fix twig error lineno off by 2

fixed regression when calling a macro inside another one (closes #889)

fixed typo

udpated CHANGELOG

added a test for previous merge (refs #892)

merged branch char101/fix-ext-crash-on-undef-func-inside-macro (PR #892)

This PR was merged into the master branch.

Commits
-------

55b76c1 Fix extension crash when calling unknown method inside a macro

Discussion
----------

Fix extension crash when calling unknown method inside a macro

 Issue #890

fixed CS

merged branch char101/optimize-strict-vars-php54 (PR #893)

This PR was squashed before being merged into the master branch (closes #893).

Commits
-------

f397a8f Use ternary operator with PHP 5.4 when strict_variables is true

Discussion
----------

Use ternary operator with PHP 5.4 when strict_variables is true

When strict variables is true, and using PHP 5.4, we can still use the ternary operator to optimize performance.

Use ternary operator with PHP 5.4 when strict_variables is true

Fix extension crash when calling unknown method inside a macro

merged branch nomack84/fixed_typo (PR #891)

This PR was merged into the master branch.

Commits
-------

cc65c88 [template_from_string]Fixed typo

Discussion
----------

[template_from_string]Fixed typo in docs

Fix a typo in the template_from_string function docs

[template_from_string]Fixed typo

bumped version to 1.11.0-DEV

prepared the 1.11.0 release

merged branch char101/fix-build-warning (PR #886)

This PR was merged into the master branch.

Commits
-------

3164ee3 Fix build warning for const pointer

Discussion
----------

Fix build warning for const pointer

 Issue #883

Fix build warning for const pointer

added a .gitignore to ignore files created when building the C extension

merged branch char101/nativeext-exception-info (PR #885)

This PR was merged into the master branch.

Commits
-------

db13b66 Pass lineno and filename to Twig_Error constructor
feee667 Merge branch 'nativeext-exception-info' of https://github.com/fabpot/Twig into nativeext-exception-info
adb31d4 Call Twig_Error constructor
d4a8c8b added tests for exceptions thrown in Twig_Template::getAttribute()
1b82bf7 Add template filename for the rest of the exception
5675140 Handle NULL filename
71f64bc Add template name to error message

Discussion
----------

Add template name to error message

Issue #884

---------------------------------------------------------------------------

by fabpot at 2012-11-06T07:43:16Z

For some unknown reasons, I don't see your branch when I try to submit a PR. Can you cherry-pick my unit tests from my `nativeext-exception-info` branch?

---------------------------------------------------------------------------

by Tobion at 2012-11-06T08:29:19Z

@char101 Maybe you could also integrate the fixes of #878?

---------------------------------------------------------------------------

by fabpot at 2012-11-06T08:30:55Z

@Tobion Let's do one thing at a time.

---------------------------------------------------------------------------

by char101 at 2012-11-06T08:59:30Z

@Tobion AFAIK, unlike the PHP implementation, the C implementation does not automatically convert array key type.

---------------------------------------------------------------------------

by char101 at 2012-11-06T09:27:54Z

@fabpot How about the lineno variable? Should I just set it to 0 or is there any function that can be called to obtain it?

```php
if (-1 === $this->lineno || null === $this->filename) {
    $this->guessTemplateInfo();
}
```

---------------------------------------------------------------------------

by fabpot at 2012-11-06T09:32:09Z

You need to keep `-1` for the line.

---------------------------------------------------------------------------

by char101 at 2012-11-06T09:36:56Z

If `$lineno` is `-1`, wouldn't `$this->guessTemplateInfo()` still be called?

---------------------------------------------------------------------------

by fabpot at 2012-11-06T09:45:34Z

Yes, but the template name will not be guessed. So, there is a performance overhead for the line guessing, but not for the template name guessing.

Pass lineno and filename to Twig_Error constructor

Merge branch 'nativeext-exception-info' of https://github.com/fabpot/Twig into nativeext-exception-info

Call Twig_Error constructor

added tests for exceptions thrown in Twig_Template::getAttribute()

Add template filename for the rest of the exception

Handle NULL filename

Add template name to error message

fixed macro compilation when a variable name is a PHP reserved keyword (closes #881)

fixed CS

merged branch fabpot/timezones (PR #876)

This PR was merged into the master branch.

Commits
-------

f99504a changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone
d3b0cbd merged branch jmikola/patch-1 (PR #845)
a6a1ef0 Avoid setting timezones on DateIntervals

Discussion
----------

changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone

This PR is based on #845, and addresses issue #778.

Right now, the timezone management when using the date filter is counter-intuitive. When you pass a DateTime object, the default timezone is not applied, but in all other cases, it is.

This PR makes the behavior more consistent by always applying the default timezone (which is probably what users want most of the time), and this can be disabled by explicitly passing ``false`` as the timezone value.

This is a BC break but I think that not many consciously rely on the current behavior.

---------------------------------------------------------------------------

by fabpot at 2012-10-30T15:49:13Z

@jmikola Can you have a look at this PR and tell me your opinion about this change?

---------------------------------------------------------------------------

by jmikola at 2012-11-02T20:17:30Z

@fabpot: Will take a look at this tonight. I missed the notifications as I was offline for a few days.

---------------------------------------------------------------------------

by jmikola at 2012-11-03T04:09:54Z

I read through all of the issues and PR's and this looks reasonable. Are we missing a test case for passing in a DateTime object with `false` for the timezone? I do see one example where we render the current date using the `'e'` format string and provide `false` for the timezone, but that's it.

---------------------------------------------------------------------------

by fabpot at 2012-11-03T07:09:08Z

ok, I've added an additional test just to be sure.

changed the date filter behavior to always apply the default timezone, except if false is passed as the timezone