Tokeniser issue for function call parenthesis - inside switch

[michalbundyra]

Describe the bug

Since 3.10.0 (PR: #461) we have new tokens - T_TYPE_(OPEN|CLOSE)_PARENTHESIS and as I understand these should be used just for DNF types, so tokens for function calls should remain unchanged.

Here is the small example when it is wrong:

Code sample

<?php

declare(strict_types=1);

namespace FooBar;

\Bar\Baz\barBaz(); // <-- it is OK here, T_(OPEN|CLOSE)_PARENTHESIS

switch (true) {
    case 1:
        \Name\functionInSwitch(); // <-- it is wrong here T_TYPE_(OPEN|CLOSE)_PARENTHESIS
        break;
}

Custom ruleset

N/A

To reproduce

Just check tokens on the above code sample using the latest version and version pre-3.10.0.

Expected behavior

In the above example we should get T_(OPEN|CLOSE)_PARENTHESIS tokens in both cases.

Versions (please complete the following information)

Operating System	-
PHP version	8.3
PHP_CodeSniffer version	3.10.3, master
Standard	-
Install type	-

Additional context

N/A

Please confirm

• I have searched the issue list and am not opening a duplicate issue.
• I have read the Contribution Guidelines and this is not a support question.
• I confirm that this bug is a bug in PHP_CodeSniffer and not in one of the external standards.
• I have verified the issue still exists in the master branch of PHP_CodeSniffer.

[jrfnl]

@michalbundyra Thank you for reporting this! I've been able to reproduce and confirm the bug. The problem is with the colon for case confusing the retokenization (which thinks it's a return type).

Are you already working on this ? If not, I'll try to have a look over the next few days.

[michalbundyra]

@jrfnl thanks for checking and confirming. I was investigating it a bit more, but I couldn't find a solution, and the tokenizer is quite tricky. I have noticed tho that the same issue we would have in other cases with :, for example:

 if (true):
     \B\call();
 endif;

I guess this is not very popular way of writing stuff, but still valid and it is not tokenised in the correct way.

I think I will leave it for now, so if you have some time to have a look that would be great. Thanks 🙏

[jrfnl]

@michalbundyra Good catch. Thanks for the additional code sample. A previous bug was also related to the "wrong" colon, so I clearly had a blind spot for those when I was coding this up ;-) I'll have a look later.

[jrfnl]

@michalbundyra PR #632 should fix this, though I have to admit my brain is not coming up with sufficient code samples to test this more strenuously at the moment, so RL testing (and potentially adding extra code samples to the tests) would be very much appreciated.

[michalbundyra]

@jrfnl I was looking into it and verified with couple more examples, but it looks like you've covered everything already.
The other cases I was thinking are ternary operator and named parameters, but it all works fine. I checked also with while/for/foreach loops with ::

namespace E {
    if ($c1):
        \A\call1();
    elseif ($c2):
        \B\call2();
    else:
        \C\call3();
    endif;

    while ($c3):
        \D\call4();
    endwhile;

    for ($i = 0; $i < 10; $i++):
        \F\call5();
    endfor;

    foreach ($array as $key => $value):
        \G\call6();
    endforeach;

    label:
        \D\call7();

    $var1 ? \X\call8() : \Y\call9();
    $var2 ?: \Z\call10();

    \Z1\call11(
        param1: \Z2\call12(),
        param2: fn (): int|(\Countable&\Iterable) => \Z3\call13(),
        param3: function (): int|(\DateTime&\ArrayObject) {
            return \Z4\call14();
        },
    );
}

also tested with WebimpressCodingStandard, as it is were I notice the issue, and the branch with the fix works all good there.

Thanks!

[jrfnl]

Thank you for testing this so thoroughly @michalbundyra! If it's okay with you, I'll add those extra code samples to the tests. Even though it all works, having extra tests to make sure it all continues to work as it should in the future is never a bad thing.

I think I'll leave the PR open for a few more days to give more people the chance to look it over and test, but the fix will be included in the 3.11.0 release for sure.