Missing a curly brace at the end of a class causes `OutsideObjectContext`

[Anna Filina]

Bug Description

Missing a curly brace at the end of a class causes the OutsideObjectContext sniff to unexpectedly report errors.

Given the following reproduction Scenario

The issue happens when running this command:

phpcs -ps file.php --standard=PHPCompatibility --runtime-set testVersion 8.1

... over a file containing this code:

class MyClass
{
    private $property;

    function myMethod()
    {
        return $this->property;
    }
    
// note the missing curly brace at the end of the class

I'd expect the following behaviour

A warning about file having invalid syntax on line N, therefore some sniffs won't work correctly, and skip the OutsideObjectContext sniff. Although this is up to the maintainers.

Instead this happened

PHPCompatibility.Variables.ForbiddenThisUseContexts.OutsideObjectContext

Environment

Environment	Answer
PHP version	8.2.3
PHP_CodeSniffer version	3.5.3
PHPCompatibility version	(not sure how to check inside PHPCO, lastest as of 2023-04-11)
Install type	PHPCO

Tested Against develop branch?

• I have verified the issue still exists in the develop branch of PHPCompatibility.

[Juliette]

@afilina Ah, well, this is one we can't solve.

All PHPCS results are unreliable in the case of parse errors.
As much of possible, sniffs are written in a way to "stay silent" when parse errors or live coding is detected, so in most cases, sniffs will underreport. In rare cases, like here, this causes false positives.

A warning about file having invalid syntax on line N, therefore some sniffs won't work correctly

That is not something for PHPCompatibility to implement, but for the PHP_CodeSniffer runner.

IIRC this has been discussed before in that repo and the answer was simply: if you want PHPCS results to be reliable, run a linter before running PHPCS or add the Generic.PHP.Syntax sniff to your ruleset, which will lint the code using php -l.

In my experience, the Generic.PHP.Syntax sniff is very slow, so I'd recommend using something like PHP Parallel Lint instead.

PHP_CodeSniffer version | 3.5.3
PHPCompatibility version | (not sure how to check inside PHPCO, lastest as of 2023-04-11)

For the PHPCompatibility version, just say develop and if you have it, the commit hash of the develop version.

As for this combination of PHPCS and PHPCompatibility: this is not a supported combination anymore and will lead to errors and false positives/false negatives.

The minimum supported PHPCS version for PHPCompatibility develop/10.0.0 is PHPCS 3.7.1 (and has been since Sept 2022).

Install type | PHPCO

Not sure what you mean by that ? What we're looking for is along the lines of e.g. Composer global, Composer project local, git clone, other (please expand)

[Anna Filina]

As for this combination of PHPCS and PHPCompatibility: this is not a supported combination anymore and will lead to errors and false positives/false negatives.

I have since installed the latest versions via Composer. There were too many other constraints with PHPCO anyway.

IIRC this has been discussed before in that repo and the answer was simply: if you want PHPCS results to be reliable, run a linter before running PHPCS or add the Generic.PHP.Syntax sniff to your ruleset, which will lint the code using php -l.

In my experience, the Generic,PHP.Syntax sniff is very slow, so I'd recommend using something like PHP Parallel Lint instead.

Thanks for the advice. I'll probably write an article on this topic after this project, both for the community and as a reminder for myself.

Feel free to close the issue.

[Juliette]

I have since installed the latest versions via Composer.

👍🏻

There were too many other constraints with PHPCO anyway.

Not sure what you mean by that ?