PHPCompatibility / PHPCompatibility

PHP Compatibility check for PHP_CodeSniffer

Home Page:http://techblog.wimgodden.be/tag/codesniffer/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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 to warning.
  • 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