added some missing test for Template::getAttribute()
Fix empty string comparison
added some missing test for Template::getAttribute()
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
fixed some tests when the extension is not enabled
added a missing test
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
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.
added an exception when misusing macro calls (refs #922)
moved some code to the proper location
added a note about the PEAR package
added a note about deprecated interfaces
added Twig_TemplateInterface in the list of deprecated interfaces
added the ability to use any PHP callable to define filters, functions, and tests
added @deprecated tags on deprecated classes
simplified code
added a syntax error when using a loop variable that is not defined (closes #925)
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
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.
fixed regression