merged branch Seldaek/inception (PR #610)
authorFabien Potencier <fabien.potencier@gmail.com>
Tue, 24 Jan 2012 18:09:17 +0000 (19:09 +0100)
committerFabien Potencier <fabien.potencier@gmail.com>
Tue, 24 Jan 2012 18:09:17 +0000 (19:09 +0100)
commitb45f6b9bfcca3cf6d772011a135a34b212d62316
treee996eae5038a97ab08ae271945f313ad80fac523
parenta494438a0c3ffb2504f58749bba915933ed91824
parent0d656f53afcb2784a341423a34442461cfc365b1
merged branch Seldaek/inception (PR #610)

Commits
-------

0d656f5 Add comments
0255764 Updated CHANGELOG
b327a48 Protect the Parser against recursive parsing issues

Discussion
----------

Make the parser Inception-Proof

Spent half a day debugging before I realized what happened, but I'll try to keep a long story short:

When the cache is empty, and the first template containing an assetic `{% javascripts %}` or similar tag is parsed, it will build up the assetic "assets" or recipes cache, this in turn will tokenize and parse all your templates to find assetic tags and cache that information.

At this point the parser is parsing something else in the middle of a parse() call, and since there is a single instance in the environment, it means all the instance vars are messed up and contain incorrect references to the latest TokenStream that was parsed by assetic, etc.

This had two effects on my application, both appearing seemingly randomly because it highly depends on the order of things, the state of your cache and probably other factors:

- The first thing that happened is that a template was compiled using the wrong template filename, which means I had a `__TwigTemplate_abcd` in the file named `dcba.php`, and it would never find the right class.
- The second issue (could not reproduce but I assume it was caused by this as well) is that the parse tree is completely broken and you end up with a parse error because it thinks it's at the end when it's not, or similar problem.

The proposed fix basically pushes/pops all the vars into a stack whenever the parser starts/stops, which worked very effectively here and does not introduce much breakage or complexity.

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

by stof at 2012-01-24T17:28:06Z

@Seldaek are you able to create a reproducible testcase for this (which should be failing before this fix) ? It would avoid further regressions

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

by Seldaek at 2012-01-24T17:45:37Z

I'll try to improve on this according to feedback tomorrow. I saw this enough for today :)

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

by fabpot at 2012-01-24T17:45:49Z

I'm writing some unit tests

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

by Seldaek at 2012-01-24T17:47:02Z

Ok then I'll add @dzuelke's comments real quick.