Hi!
https://github.com/sebastianbergmann/diff/blob/master/tests/ParserTest.php#L79
triggers a
Parse error: Invalid body indentation level (expecting an indentation
level of at least 1) in /path/to/ParserTest.php on line 79
with current PHP 7.3.0-dev (master); the code in question works fine with
PHP 7.1 and PHP 7.2.
Is this intended behavior? Is this related to
https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes?
On Mon, May 28, 2018 at 2:24 PM, Sebastian Bergmann sebastian@php.net
wrote:
Hi!
https://github.com/sebastianbergmann/diff/blob/
master/tests/ParserTest.php#L79
triggers aParse error: Invalid body indentation level (expecting an indentation
level of at least 1) in /path/to/ParserTest.php on line 79with current PHP 7.3.0-dev (master); the code in question works fine with
PHP 7.1 and PHP 7.2.Is this intended behavior? Is this related to
https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes?
Yes, this is an expected result under the flexible heredoc RFC. To avoid
issues, please use a heredoc label that does not occur within the string.
Nikita
Am 28.05.2018 um 14:51 schrieb Nikita Popov:
Yes, this is an expected result under the flexible heredoc RFC. To avoid
issues, please use a heredoc label that does not occur within the string.
Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP
7.3. This breaking change should at least be prominently documented. As of
right now, I do not see such documentation in UPGRADING.
Yes, this is an expected result under the flexible heredoc RFC. To avoid
issues, please use a heredoc label that does not occur within the string.Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP
7.3. This breaking change should at least be prominently documented. As of
right now, I do not see such documentation in UPGRADING.
Wow, I can't believe I didn't think of this when I reviewed that RFC.
This is potentially a pretty serious BC break, really - at least in two cases:
-
Markdown, where indentation can be irregular as well as meaningful.
-
Failing tests!
The latter could prove rather difficult - getting your tests to pass
under 7.2 and 7.3+ might be far from simple, and at the very least
would require test-helpers that conditionally treat whitespace
differently for 7.3+ and earlier versions.
Even inline HTML could potentially suffer, if you have <pre> blocks.
And on top of these unexpected results and test-failures, of course
there may be parse errors for inline content with meaningful
whitespace that was (or wasn't) indented correctly.
Honestly, are there any cases where existing code benefits from
changing the existing syntax/feature?
Some people indent inline blocks so that the output ends up with the
desired indentation, rather than the source-code looking pretty - in
those cases, whitespace will now be silently removed and the output no
longer as desired?
Are we positive it wouldn't be safer to just introduce a slight syntax
variation for blocks that treat indentation differently?
(am I blowing this out of proportion?)
Yes, this is an expected result under the flexible heredoc RFC. To avoid
issues, please use a heredoc label that does not occur within the string.Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP
7.3. This breaking change should at least be prominently documented. As of
right now, I do not see such documentation in UPGRADING.Wow, I can't believe I didn't think of this when I reviewed that RFC.
This is potentially a pretty serious BC break, really - at least in two cases:
Markdown, where indentation can be irregular as well as meaningful.
Failing tests!
The latter could prove rather difficult - getting your tests to pass
under 7.2 and 7.3+ might be far from simple, and at the very least
would require test-helpers that conditionally treat whitespace
differently for 7.3+ and earlier versions.Even inline HTML could potentially suffer, if you have <pre> blocks.
And on top of these unexpected results and test-failures, of course
there may be parse errors for inline content with meaningful
whitespace that was (or wasn't) indented correctly.Honestly, are there any cases where existing code benefits from
changing the existing syntax/feature?
No.
Some people indent inline blocks so that the output ends up with the
desired indentation, rather than the source-code looking pretty - in
those cases, whitespace will now be silently removed and the output no
longer as desired?
No.
Are we positive it wouldn't be safer to just introduce a slight syntax
variation for blocks that treat indentation differently?(am I blowing this out of proportion?)
It seems that you have not understood the change. While formerly the
actual string had exactly the noted whitespace at the beginning of the
lines, now the leading whitespace of the line with the closing marker is
also removed for all other lines (but not additional leading
whitespace). See the first two examples in the “Closing Marker
Indentation” section[1].
The BC break affects only code which has the heredoc/nowdoc identifier
in the body of the string, namely at the beginning of a line (with
optional leading whitespace).
[1]
https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes#closing_marker_indentation
--
Christoph M. Becker
On Mon, May 28, 2018 at 3:32 PM, Sebastian Bergmann sebastian@php.net
wrote:
Am 28.05.2018 um 14:51 schrieb Nikita Popov:
Yes, this is an expected result under the flexible heredoc RFC. To avoid
issues, please use a heredoc label that does not occur within the string.Hmkay, so code that worked fine with PHP 7.1 and PHP 7.2 breaks with PHP
7.3. This breaking change should at least be prominently documented. As of
right now, I do not see such documentation in UPGRADING.
Good point, I have added a note in UPGRADING in
https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c
.
Nikita
Am 28.05.2018 um 22:16 schrieb Nikita Popov:
Good point, I have added a note in UPGRADING in
https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c
Thank you so much, Nikita!
Am Di., 29. Mai 2018 um 07:34 Uhr schrieb Sebastian Bergmann <
sebastian@php.net>:
Am 28.05.2018 um 22:16 schrieb Nikita Popov:
Good point, I have added a note in UPGRADING in
https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c
Thank you so much, Nikita!
Can't we ignore any delimiter occurrence that's indented more than the
previous lines to keep the BC break lower?
Regards, Niklas
Op di 29 mei 2018 om 10:27 schreef Niklas Keller me@kelunik.com:
Am Di., 29. Mai 2018 um 07:34 Uhr schrieb Sebastian Bergmann <
sebastian@php.net>:Am 28.05.2018 um 22:16 schrieb Nikita Popov:
Good point, I have added a note in UPGRADING in
https://github.com/php/php-src/commit/c70468b8d3c1d6711da0db84cba30d87d2482e5c
Thank you so much, Nikita!
Can't we ignore any delimiter occurrence that's indented more than the
previous lines to keep the BC break lower?Regards, Niklas
Everyone,
It might seem obvious and i've probably missed the reasoning, but if the
identifier isn't followed by ; then it shouldn't be treated as the
delimiter right? Am i missing something here?
Just my 2cents ;)