Parse error: Invalid body indentation level

php.internals

Sebastian Bergmann

8 years ago
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?

Nikita Popov

8 years ago
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 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? >
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

Sebastian Bergmann

8 years ago
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.

Rasmus Schultz

8 years ago
> > 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: 1. Markdown, where indentation can be irregular as well as meaningful. 2. 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?)

Christoph Becker

8 years ago
On 28.05.2018 at 18:56, Rasmus Schultz wrote:
>>> 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: > > 1. Markdown, where indentation can be irregular as well as meaningful. > > 2. 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

Nikita Popov

8 years ago
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

Sebastian Bergmann

8 years ago
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!

Niklas Keller

8 years ago
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

Kingsquare.nl - Robin Speekenbrink

8 years ago
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 ;)