Deprecate curly brace syntax for array/string offset access #4416

theodorejb · 2019-07-15T16:50:54Z

RFC: https://wiki.php.net/rfc/deprecate_curly_braces_array_access

Migration script: https://gist.github.com/theodorejb/763b83a43522b0fc1755a537663b1863

@rjhdby wrote the initial deprecation patch and migration script. I added commits to improve the script, convert uses in run-tests.php, and move the migration script to a GitHub gist (since I don't think it makes sense to maintain it long-term in php-src).

…522b0fc1755a537663b1863 This script isn't something that should be maintained long term in php-src.

nikic

Please check whether const FOO = "BAR"{0} throws a deprecation warning. You might need additional handling in zend_compile_const_expr or maybe zend_eval_const_expr.

Zend/zend_compile.h

tests/strings/offsets_general.phpt

…h ZEND_DIM_IS This was causing the constant_expressions_coalesce.phpt test to fail.

theodorejb · 2019-07-16T17:38:52Z

@nikic I hope I'm doing things the right way. It seems kind of hacky how ast->child[0]->attr is overwritten here: https://github.com/theodorejb/php-src/blob/41878385bd976fb566f73496dc759a6093f6704f/Zend/zend_compile.c#L8811. I changed the value of ZEND_ALTERNATIVE_ARRAY_SYNTAX to avoid conflicting with ZEND_DIM_IS, but there's still the following bug:

const A = [1 => [[]]];

const T_0 = A[1]{0}; // produces deprecation notice as expected
const T_1 = A[1]{0} ?? 1; // fails to produce deprecation notice

… coalescing operator

theodorejb · 2019-07-16T22:55:39Z

@nikic I worked around the issue of ast->child[0]->attr being overwritten by treating it as a bitmask instead of a single value. Still seems hacky but it works!

Zend/zend_language_parser.y

nikic · 2019-07-17T15:13:56Z

As mentioned above, it is better to throw the deprecation warning in the compiler so that tooling that only parses (php-ast extension and token_get_all in parse mode) does not generate deprecation warnings. I think the patch you used to have was right. Instead of using a bitmask you might want to remove the flag after emitting the deprecation warning in eval_const_expr -- I think duplicate warnings might happen otherwise.

This reverts commit 8131dbc.

theodorejb · 2019-07-17T16:08:52Z

@nikic Okay, I reverted the direct parser implementation to avoid warnings for tooling that needs to parse PHP files.

Without the bitmask approach, though, I'm not sure how to generate the correct deprecation warning when the null coalesce operator is used (since it otherwise overwrites the attr property on child nodes before they are evaluated).

Can you think of an example that would produce duplicate warnings?

nikic · 2019-07-18T09:24:13Z

@theodorejb Okay, seeing where the DIM_IS flag is being set, the bitmask is fine. I'd suggest renaming to ZEND_DIM_ALTERNATIVE_SYNTAX and placing the defines next to each other as (1 << 0) and (1 << 1) to make clear that this is a bitmask though.

For the duplicate warning, I'm thinking something like [$x{0}] might trigger it -- I think this will try to const-eval the $x{0}, throw a deprecation warning there and then again during compilation.

nikic · 2019-07-19T08:07:10Z

Merged as d574df6, thanks!

> The array and string offset access syntax using curly braces is deprecated. > Use $str[$idx] instead of $str{$idx}. Refs: * https://wiki.php.net/rfc/deprecate_curly_braces_array_access * https://github.com/php/php-src/blob/ef165b4422f4cef60f963833dddffa26fe1b2759/UPGRADING#L351-L353 * php/php-src#4416 * php/php-src@d574df6 ## Implementation notes Based on a lot of testing, I have come to the conclusion that the curly braces for array access *only* worked when used on a variable/property. It never worked on constant arrays, function calls etc etc Note: * Verified that curly brace syntax never worked for function array string dereferencing. See https://3v4l.org/oWnqF * Verified that curly brace syntax never worked for function array dereferencing. See https://3v4l.org/g9jGG * Verified that curly brace syntax never worked for new class member access. See https://3v4l.org/9PkVW ## Fixes In contrast to any other PHPCompatibility sniff, this sniff contains an auto-fixer. For larger codebases, this issue can be quite time-consuming to fix, while fixing this automatically is trivial. This also makes this sniff a fully fledged alternative to the [migration script](https://gist.github.com/theodorejb/763b83a43522b0fc1755a537663b1863) provided by PHP itself. *Important*: At this moment, the PHPCompatibility unit test suite does not contain a mechanism to test the fixer. ## Tests run I have run the sniff, as well as the fixer, over a number of medium to large codebases and have found _no_ false positives. I have compared the results of a few of these projects with [the list compiled by Nikita](https://gist.github.com/nikic/b5f811e0423bf051f4492cd6e0c0273e) and the results are 100% the same.

> The array and string offset access syntax using curly braces is deprecated. > Use $str[$idx] instead of $str{$idx}. Refs: * https://wiki.php.net/rfc/deprecate_curly_braces_array_access * https://github.com/php/php-src/blob/ef165b4422f4cef60f963833dddffa26fe1b2759/UPGRADING#L351-L353 * php/php-src#4416 * php/php-src@d574df6 Based on a lot of testing, I have come to the conclusion that the curly braces for array access *only* worked when used on a variable/property. It never worked on constant arrays, function calls etc etc Note: * Verified that curly brace syntax never worked for function array string dereferencing. See https://3v4l.org/oWnqF * Verified that curly brace syntax never worked for function array dereferencing. See https://3v4l.org/g9jGG * Verified that curly brace syntax never worked for new class member access. See https://3v4l.org/9PkVW In contrast to any other PHPCompatibility sniff, this sniff contains an auto-fixer. For larger codebases, this issue can be quite time-consuming to fix, while fixing this automatically is trivial. This also makes this sniff a fully fledged alternative to the [migration script](https://gist.github.com/theodorejb/763b83a43522b0fc1755a537663b1863) provided by PHP itself. *Important*: At this moment, the PHPCompatibility unit test suite does not contain a mechanism to test the fixer. I have run the sniff, as well as the fixer, over a number of medium to large codebases and have found _no_ false positives. I have compared the results of a few of these projects with [the list compiled by Nikita](https://gist.github.com/nikic/b5f811e0423bf051f4492cd6e0c0273e) and the results are 100% the same.

> The array and string offset access syntax using curly braces is deprecated. > Use $str[$idx] instead of $str{$idx}. Refs: * https://wiki.php.net/rfc/deprecate_curly_braces_array_access * https://github.com/php/php-src/blob/ef165b4422f4cef60f963833dddffa26fe1b2759/UPGRADING#L351-L353 * php/php-src#4416 * php/php-src@d574df6 Based on a lot of testing, I have come to the conclusion that the curly braces for array access worked in quite a lot of cases, though mostly since PHP 7.0. The other sniffs which should take curly brace access into account - `NewArrayStringDereferencing`, `NewClassMemberAccess` and `NewFunctionArrayDereferencing` - have been adjusted in separate PRs. This PR can only be merged after those PRs have been merged. ### Other tests Based on the above mentioned tests, I also found that - yes, curly brace array access is supported on constants, but only when the first set of braces is square brackets. See: * https://3v4l.org/WIUHk * https://3v4l.org/OWSq6 * https://3v4l.org/e6YWk ### Fixer In contrast to any other PHPCompatibility sniff, this sniff contains an auto-fixer. For larger codebases, this issue can be quite time-consuming to fix, while fixing this automatically is trivial. This also makes this sniff a fully fledged alternative to the [migration script](https://gist.github.com/theodorejb/763b83a43522b0fc1755a537663b1863) provided by PHP itself. *Important*: At this moment, the PHPCompatibility unit test suite does not contain a mechanism to test the fixer. A typical `.fixed` file which would be expected by the PHPCS native test suite to verify the fixer results _is_ included with this PR though. I have run the sniff, as well as the fixer, over a number of medium to large codebases and have found _no_ false positives. I have compared the results of a few of these projects with [the list compiled by Nikita](https://gist.github.com/nikic/b5f811e0423bf051f4492cd6e0c0273e) and for the compared results, the outcome is 100% the same.

> The array and string offset access syntax using curly braces is deprecated. > Use $str[$idx] instead of $str{$idx}. Refs: * https://wiki.php.net/rfc/deprecate_curly_braces_array_access * https://github.com/php/php-src/blob/ef165b4422f4cef60f963833dddffa26fe1b2759/UPGRADING#L351-L353 * php/php-src#4416 * php/php-src@d574df6 ## Implementation notes Based on a lot of testing, I have come to the conclusion that the curly braces for array access worked in quite a lot of cases, though mostly since PHP 7.0. The other sniffs which should take curly brace access into account - `NewArrayStringDereferencing`, `NewClassMemberAccess` and `NewFunctionArrayDereferencing` - have been adjusted in separate PRs. This PR can only be merged after those PRs have been merged as it re-uses logic from those sniffs. ### Other tests Based on the above mentioned tests, I also found that - yes, curly brace array access is supported on constants, but only when the first set of braces is square brackets. See: * https://3v4l.org/WIUHk * https://3v4l.org/OWSq6 * https://3v4l.org/e6YWk ## Auto-fixing In contrast to any other PHPCompatibility sniff, this sniff contains an auto-fixer. For larger codebases, this issue can be quite time-consuming to fix, while fixing this automatically is trivial. This also makes this sniff a fully fledged alternative to the [migration script](https://gist.github.com/theodorejb/763b83a43522b0fc1755a537663b1863) provided by PHP itself. **Important**: At this moment, the PHPCompatibility unit test suite does not contain a mechanism to test the fixer. A typical `.fixed` file which would be expected by the PHPCS native test suite to verify the fixer results _is_ included with this PR though. ## Tests run I have run the sniff, as well as the fixer, over a number of medium to large codebases and have found _no_ false positives. I have compared the results of a few of these projects with [the list compiled by Nikita](https://gist.github.com/nikic/b5f811e0423bf051f4492cd6e0c0273e) and for the compared results, the outcome is 100% the same.

Jan-E · 2020-07-07T10:45:24Z

Looks like you missed 2 places in the win32 build system:
https://github.com/php/php-src/blob/PHP-7.4/win32/build/mkdist.php#L189
https://github.com/php/php-src/blob/PHP-7.4/win32/build/mkdist.php#L192

Since the windows build system has moved to using PHP 7.4 the deprecation warning is also shown when building PHP 7.3. @cmb69 something for you to correct?

cmb69 · 2020-07-07T11:06:23Z

@Jan-E, indeed, that needs to be fixed. Thanks for reporting! :)

Jan-E · 2020-07-07T11:19:09Z

PHP 7.2 has the same problem, but this is not exactly a security fix;
https://github.com/php/php-src/blob/PHP-7.2/win32/build/mkdist.php#L194

cmb69 · 2020-07-07T12:01:49Z

I'm not concerned about PHP 7.2. This will EOL around the time PHP 8.0.0 will be released, and certainly the SDK will not be updated to PHP 8.0 soon afterwards. And if anybody will build PHP 7.2 after the SDK had been updated to PHP 8.0, they still could use a slightly older SDK version (or apply the fix themselves). And with PHP 7.4, it's just a deprecation notice.

rjhdby and others added 8 commits July 15, 2019 11:29

deprecation

4149edc

update tests

8044b7a

token replaced by constant

e1fe349

migration script

42cb84a

migration script

41a906c

Fix migration script and run it on run-tests.php

c1163dd

Move migration script to https://gist.github.com/theodorejb/763b83a43…

5d79e94

…522b0fc1755a537663b1863 This script isn't something that should be maintained long term in php-src.

Replace deprecated curly brace uses in fcgi.inc

f666b7d

petk added the RFC label Jul 15, 2019

nikic reviewed Jul 16, 2019

View reviewed changes

Zend/zend_compile.h Outdated Show resolved Hide resolved

tests/strings/offsets_general.phpt Outdated Show resolved Hide resolved

tests/strings/offsets_general.phpt Show resolved Hide resolved

nikic added this to the PHP 7.4 milestone Jul 16, 2019

theodorejb added 2 commits July 16, 2019 10:33

Improve test coverage and handle deprecated syntax in const expressions

e938af5

Change ZEND_ALTERNATIVE_ARRAY_SYNTAX value so it doesn't conflict wit…

4187838

…h ZEND_DIM_IS This was causing the constant_expressions_coalesce.phpt test to fail.

Output correct notice when deprecated curly braces are used with null…

292c23c

… coalescing operator

Girgias reviewed Jul 17, 2019

View reviewed changes

Zend/zend_language_parser.y Show resolved Hide resolved

nikic reviewed Jul 17, 2019

View reviewed changes

Zend/zend_language_parser.y Outdated Show resolved Hide resolved

Merge branch 'upstream/PHP-7.4'

29145dd

theodorejb force-pushed the deprecate_alternate_array_access branch from d64424f to 8ddac63 Compare July 17, 2019 12:31

Implement directly in parser to avoid compiler complications

8131dbc

theodorejb force-pushed the deprecate_alternate_array_access branch from 8ddac63 to 8131dbc Compare July 17, 2019 13:08

Revert "Implement directly in parser to avoid compiler complications"

5d2ae42

This reverts commit 8131dbc.

theodorejb added 3 commits July 18, 2019 09:28

Merge branch 'upstream/PHP-7.4'

fe08153

Rename flag to clarify bitmask usage

e80b265

Prevent duplicate warning from const evaluation and compilation

4c791b1

nikic approved these changes Jul 19, 2019

View reviewed changes

nikic closed this Jul 19, 2019

theodorejb deleted the deprecate_alternate_array_access branch July 22, 2019 16:10

jrfnl mentioned this pull request Jul 29, 2019

PHP 7.4: New RemovedCurlyBraceArrayAccess sniff PHPCompatibility/PHPCompatibility#855

Merged

sakalauskas mentioned this pull request Jan 9, 2020

remove deprecated access postaddictme/instagram-php-scraper#572

Closed

yurii-github mentioned this pull request Feb 5, 2020

Fix stable - "Array and string offset access syntax with curly braces is deprecated in php 7.4" dokuwiki/dokuwiki#2978

Closed

kabalin mentioned this pull request Dec 23, 2020

Using PHP 7.0.x and getting PHP deprication error specific to 7.4 shivammathur/setup-php#384

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Deprecate curly brace syntax for array/string offset access #4416

Deprecate curly brace syntax for array/string offset access #4416

Uh oh!

theodorejb commented Jul 15, 2019

Uh oh!

nikic left a comment •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Uh oh!

theodorejb commented Jul 16, 2019 •

edited

Loading

Uh oh!

theodorejb commented Jul 16, 2019

Uh oh!

Uh oh!

Uh oh!

nikic commented Jul 17, 2019

Uh oh!

theodorejb commented Jul 17, 2019

Uh oh!

nikic commented Jul 18, 2019

Uh oh!

nikic commented Jul 19, 2019

Uh oh!

Jan-E commented Jul 7, 2020

Uh oh!

cmb69 commented Jul 7, 2020

Uh oh!

Jan-E commented Jul 7, 2020

Uh oh!

cmb69 commented Jul 7, 2020

Uh oh!

Uh oh!

Deprecate curly brace syntax for array/string offset access #4416

Deprecate curly brace syntax for array/string offset access #4416

Uh oh!

Conversation

theodorejb commented Jul 15, 2019

Uh oh!

nikic left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

theodorejb commented Jul 16, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theodorejb commented Jul 16, 2019

Uh oh!

Uh oh!

Uh oh!

nikic commented Jul 17, 2019

Uh oh!

theodorejb commented Jul 17, 2019

Uh oh!

nikic commented Jul 18, 2019

Uh oh!

nikic commented Jul 19, 2019

Uh oh!

Jan-E commented Jul 7, 2020

Uh oh!

cmb69 commented Jul 7, 2020

Uh oh!

Jan-E commented Jul 7, 2020

Uh oh!

cmb69 commented Jul 7, 2020

Uh oh!

Uh oh!

nikic left a comment •

edited

Loading

theodorejb commented Jul 16, 2019 •

edited

Loading