Tokenizer fails to match T_INLINE_ELSE when used after function call containing closure

[LastRide]

Hi.

I have next code:

<?php

class Foo
{
    private $foo;

    public function __construct($bar)
    {
        $this->foo = \is_array($bar)
            ? \array_map(
                function () {
                    return null;
                },
                $bar
            ) : $bar;
    }

    public function build(array $bar): array
    {
        return $bar;
    }
}

src/Files/File::getTokens() for ":" symbol in string public function build(array $bar): array returns "T_INLINE_ELSE" instead of "T_COLON" type.

If I change my code to:

<?php

class Foo
{
    private $foo;

    public function __construct($bar)
    {
        $this->foo = \is_array($bar)
            ? $bar
            : \array_map(
                function () {
                    return null;
                },
                $bar
            );
    }

    public function build(array $bar): array
    {
        return $bar;
    }
}

":" symbol would correctly parsed with "T_COLON" type.

[jrfnl]

Confirmed on current master. Loosely related to issues #1442, #1782.

[gsherwood]

Thanks for reporting this. It will be fixed in the next release.

The problem was caused by the code that tries to determine if a T_COLON is actually a return type separator or an inline else operator (PHP doesn't use different tokens for these). It was making the assumption that the next open parenthesis it found was the match for the closing parentheses right before the colon, which is obviously incorrect here. The reason why the return type colon was being turned into an inline else is because the tokenizer still thought it was looking for that else statement.