NewAttributes: various improvements to make
jrfnl opened this issue · comments
The PHPCompatibility.Attributes.NewAttributes
sniff is a new sniff in PHPCompatibility 10.0.0.
While it is working correctly, I believe there are some tweaks which we should make to prevent the sniff from becoming too annoying.
This has been on my local to-do list for too long already, so I'm opening this issue to make sure it's addressed before the 10.0.0 release, especially as it came up again in a feedback thread on Twitter today.
1. Attributes which cause code loss/parse errors versus attributes which are ignored in PHP < 8.
When attributes are on a line by themselves or "trailing", they will, of course, still have no impact on PHP < 8 code, but they also won't necessarily cause any errors as they will be considered as comments in PHP < 8.
I believe it may be prudent to change the message from error
to warning
for those attributes and adjust the message text.
Alternatively (or in conjunction), I also think it may be good to have a separate error code for these so that these can be more easily ignored from a PHPCS ruleset.
#[ShouldBeWarning]
function foo(
$param1, #[ShouldBeWarning]
$param2,
#[ShouldBeWarning]
$param3,
#[ShouldBeError] $param4 // This should still be an error as `$param4` will be considered commented out in PHP < 8.
) {}
2. PHP native attributes for cross-version compatibility
PHP itself has introduced a number of attributes specifically to allow for PHP cross-version compatibility by silencing deprecation notices and such. Examples: #[ReturnTypeWillChange]
, #[AllowDynamicProperties]
.
In those cases - as long as the attribute is on a line by itself or trailing -, these attributes will not cause any loss of functionality in PHP < 8.
I believe we should adjust the sniff in one or more of the following ways (to be decided, options in the comments welcome):
- Change from
error
towarning
. - Lower the severity to something below
5
, which means the message won't show unless the user specifically passes the--severity=..
flag and sets it to the lower number. - Have a separate error code for these attributes.
- Ignore these completely.
Mind: an attribute can contain references to multiple classes - #[AllowDynamicProperties, SomeOtherAttribute]
-, so this does mean the contents of the attribute will need to be analyzed and if the attribute is not stand-alone the "default" behaviour for the sniff should prevail.
There are also a number of typical PHPStorm attributes which we may also want to treat in this same way (with their own error code). Also see: https://www.exakat.io/en/adoption-of-php-8-attributes-in-2022/
We may also want to have a look at the PHPUnit 10.0 attributes and treat them in a similar way. Ref: https://phpunit.de/announcements/phpunit-10.html