PEAR/FunctionCallSignature: bug fix - fixer creates parse errors

[jrfnl]

Originally reported in https://github.com/WordPress/WordPress-Coding-Standards/issues/2083

The fixer for the OpeningIndent error for multi-line function calls could inadvertently remove a PHP close tag (or other inline HTML content) on the previous line if the first non-whitespace token on a line was T_INLINE_HTML. In the case of a PHP close tag, this would cause a parse error in the file.

This parse error would then result in the file being incorrectly tokenized for the second fixer loop, with the <?php after the inline HTML being tokenized as below, which causes problems with other sniffs:

 13 | L1 | C 43 | CC 1 | ( 0) | T_WHITESPACE               | [  3]: ⸱⸱⸱
 14 | L1 | C 46 | CC 1 | ( 0) | T_LESS_THAN                | [  1]: <
 15 | L1 | C 47 | CC 1 | ( 0) | T_INLINE_THEN              | [  1]: ?
 16 | L1 | C 48 | CC 1 | ( 0) | T_STRING                   | [  3]: php

Fixed now.

Includes unit test.

Includes minor defensive coding fix ($first !== false) on line 345 and adding of an inline comment to clarify the code within the fixer.

[jrfnl]

Note: the test failure on PHP 8.2 is unrelated to this PR and also happening on master.

Also note that this PR will conflict (on the tests) with PR #3636. I will rebase and fix the conflict depending on which PR gets merged first.

[jrfnl]

Note: the test failure on PHP 8.2 is unrelated to this PR and also happening on master.

This is related to the PHP 8.2 disjunctive normal types feature which changed the tokenization - see: https://github.com/php/php-src/pull/9512

This needs to be fixed when support for DNF is added to the PHPCS tokenizer.

[jrfnl]

Fixed by commit https://github.com/squizlabs/PHP_CodeSniffer/commit/9445108a57b46f4e84a890788de5d2388346460a in response to issue #3666, though this PR still contains some minimal differences (defensive coding, comment + minor difference in the fix) which may be worth having a look at.

[gsherwood]

This is related to the PHP 8.2 disjunctive normal types feature which changed the tokenization

Found myself here while looking into the failure. This looks to caused by tokenization of function calls changing when the name is readonly:

$var = readonly()

So where the string readonly used to be the token T_STRING, it's now T_READONLY. The code still runs fine so I'm not sure if the change was intentional.

[jrfnl]

This is related to the PHP 8.2 disjunctive normal types feature which changed the tokenization

Found myself here while looking into the failure. This looks to caused by tokenization of function calls changing when the name is readonly:

$var = readonly()

So where the string readonly used to be the token T_STRING, it's now T_READONLY. The code still runs fine so I'm not sure if the change was intentional.

The change in PHP was intentional to support disjunctive normal types for readonly properties, see the issue I linked above.

class Dnf {
    private readonly (B&C)|A $d;
}

[jrfnl]

(and yeah, DNT is not going to be fun to sort out in the tokenizer.... I have a feeling we'll probably need to add T_OPEN_TYPE_PARENTHESIS and T_CLOSE_TYPE_PARENTHESIS tokens or something as otherwise the chances of sniffs which check spacing around "normal" parentheses will all start triggering on DNT, while I imagine people may want to special case those for the spacing around and inside the parentheses.)

[jrfnl]

Fixed by commit 9445108 in response to issue #3666, though this PR still contains some minimal differences (defensive coding, comment + minor difference in the fix) which may be worth having a look at.

Rebased to make the remaining changes mergable.

[jrfnl]

Closing as replaced by https://github.com/PHPCSStandards/PHP_CodeSniffer/pull/134