File::isReference has problems with some bitwise operators and class property references

[umherirrender]

In the mediawiki/core code the Squiz.WhiteSpace.OperatorSpacing was added, but it reports a false positive, see [1]
| ERROR | [x] Expected 1 space after "&" operator; 0 found | | (Squiz.WhiteSpace.OperatorSpacing.NoSpaceAfterAmp) | ERROR | [x] Expected 1 space after "&" operator; 0 found | | (Squiz.WhiteSpace.OperatorSpacing.NoSpaceAfterAmp)

It is not reported, when using the long array syntax, because T_ARRAY is checked.

[1] https://gerrit.wikimedia.org/r/#/c/371474/3/includes/parser/ParserOptions.php

[WMDE-Fisch]

For the record: This happened with version 3.0.2

[jrfnl]

@umherirrender @WMDE-Fisch I believe PR #1609 should fix this for you. The issue was not so much the short array, as it was the self:: part of the referenced variable.

[umherirrender]

Thanks for looking into this. It seems you found some more issues with the bitwise.

I had assumed the problem with the T_ARRAY, because the same code was working with the long array syntax. With the short array syntax it have only "problems" with the second and third bitwise. The first one was not reported. But fixing it proper by also checking the situation with self:: or an explicit class name would be nice.

[jrfnl]

@umherirrender You're welcome. This (and your other issue) looked like ones which the WP project would run into trouble with as well, so seemed like a good one to get fixed asap as WP is looking to fix the whole codebase in one go in the near future ;-)

I had assumed the problem with the T_ARRAY, because the same code was working with the long array syntax. With the short array syntax it have only "problems" with the second and third bitwise. The first one was not reported.

Well, short and long arrays were being treated differently in the original code, you were quite correct about that.

• For long arrays, anything within them would be seen as a reference, which led to the bitwise and in array( 'a' => CONSTANT & OTHER_CONSTANT) being incorrectly identified as a reference.
• For short arrays, if the & was directly following the opener (i.e. the first item) òr if it was following a comma and had a variable after it, it would correctly identify it as a reference, but that meant that &self::$something was incorrectly not recognized as a reference (the second and third item).

But fixing it proper by also checking the situation with self:: or an explicit class name would be nice.

That's what I'm hoping to achieve with the PR I opened, so fingers crossed that it'll be accepted.