Non-compatible Latte 3 and Latte 2 built-in tags and crash of the parser
- TomasA
- Member | 11
Hello,
I have been trying to update from Latte 2.7 to Latte 3.0. There is a problem
with parsing, when a string “default” is used as a parameter of a tag.
In Latte 2.7, the default is represented as a string and everything works fine.
In Latte 3.0, the default makes the parser to end with CompileException “Unexpected end”.
Broken tag n:class=“default”:
https://fiddle.nette.org/latte/#…
Broken tag n:href=“order! default”:
https://fiddle.nette.org/latte/#…
I see three problems in here:
- Built-in tags of Latte 2.7 and Latte 3.0 are incompatible.
- The CompileException “Unexpected end” message does not help with debugging at all. I had to figure the reason the hard way.
- Built-in tags in Latte 3.0 are not safe. They can be broken simply by a specific textual value. There is no protection.
I have discovered that I can additionally escape the default parameter (n:class=“‘default’”) as a workaround. But I don't think that should be the correct solution.
- TomasA
- Member | 11
jeremy wrote:
defaultis a reserved keyword in php, there are many of those. For examplenew,return,instanceofamong others will also throw that error.Escaping them like you did
'default'seems to be the correct way of doing it.
Definitely. However, default was a reserved keyword in php for
quite a long time and Latte 2.7 still allowed its usage in these macros. Now,
it is forbidden without any notice.
- jeremy
- Member | 50
Did you read the migration docs? Latte migration from version 2 to 3
Latte 3 is completely rewritten compared to version 2 and you should have first upgraded to version 2.11. Use the linter to find incompatibilities and then upgrade to version 3. Latte 3 is strict, so that's most likely why reserved keywords don't work anymore in these attributes.
- TomasA
- Member | 11
I did. However, I didn't run the linter yet, to be honest. I am still converting and testing my own macros from Latte 2.7 into Latte 3.0.
If I use the linter for a simple template, it returns the error: Unexpected
‘default’.
If I use it in a more complex template, it returns the error:
Unexpected end.
So it seems, that the linter really finds the error.
Still, I would expect the parser in the real usage to be more robust or to use some more explanatory notification than “Unexpected end”.