Form settings were not being maintained when subforms are involved. If a subform changed a form setting, the parent form would inherit the new value from the subform after the subform was rendered.

I'm assuming the reverse-inheritance wasn't an intended behavior. This patch saves and restores form settings as a stack so that parent forms have their original state after a subform ends.

Not sure what the hhvm test failure is; doesn't look like it was me.

Thanks for the PR.

The HHVM tests fail because of a bug in HHVM (see facebook/hhvm#3797), it's already been fixed but it seems that v3.3.1 has not been deployed to Travis CI yet.

I'm not really sure if it is a good idea to throw an Exception when the stack is empty? Wouldn't it be better to fall back to the defaults?

It seems to me that situation would be equivalent to having unbalanced pairings of opening and closing <form></form> tags on the page. It shouldn't be possible at all unless something goes very wrong, or someone manually calls the internal-use-only functions I added. Personally I would rather have the thing blow up if that somehow happens.

If you want a way to restore the defaults maybe that should be a separate function?

But if you still would rather it restore defaults let me know and I will change it.

Ok, thanks for the explanation for this behaviour.

@althaus How are you triggering {% block form_end %} without {% block form_start %}? I don't explicitly call {{ form_start(form) }} in my templates. The start and end are implicit when using {{ form(form) }}.

@vith We had some rare cases, where we had to manually render the <form> tag and then just used {{ form_end(form) }} to finalize the form with CSRF and end tag.

Nevertheless the reason I had more trouble than expected was our custom {% block form_start %} which included my patch for bootstrap-bundle which got merged inbetween (d81a349) and I just missed to remove it after updating to latest master. So sorry for causing the confusion.