Weird false positive use of unassigned variable error

darkdog

I have the following code and it's giving an error, using Laravel's class Illuminate\Support\Str:

No idea what's causing this. If I change from ! to === false it removes the error. Same if I switch to native str_starts_with().

JakubMisek

darkdog thank you for reporting the issue.

function extractByPrefix(array &$attributes)
{
    foreach ($attributes as $key => $value) {
        if (!is_string($key)) {
            continue;
        }

        /** @trace $key */

        if (!Str::startsWith($key, '')) {
            continue;
        }
    }
}

You can check what the editor thinks about variable types using mouse tool-tips or /** @trace $key */ doc block:

From the code given, I can't reproduce the issue. Isn't there more?

darkdog

Well... it's an isolated function so not sure what more I should include.

I actually tested older versions of this extension, and it seems like going from 1.63.18152 to 1.63.18172 introduces the bug for me. So I guess it must be related to these minor changes?

Inline PestPHP test case runner support. @MrPunyapal
Code completion for suggested argument string values.
Supports @psalm-assert-if-true, @psalm-assert-if-false.
Supports @phpstan-assert or psalm-assert with type hint prefixed with =, used by PHPUnit's assertInstanceOf().
Respects @phpstan-ignore-line.

Further:

What's weird is that it's almost like the extension scans twice, because it's showing two blocks of information (Use of unassigned variable '$path' and (local variable) string $path:

and it seems somewhat related to the Laravel's Str helper, because notice it doesn't complain about the $path in the Storage::disk check, only the Str one.

More information:

When I delete the vendor folder the error goes away.
I'm running a Laravel 12 project in WSL.
The error is new, it wasn't there when I worked with the code a month or so ago.
The same error shows up for similar if-checks within foreach loops all over my code.

Even the official Illuminate\Support\Str::unwrap() shows a similar error, see:

RichardAubin

I'm going to assume that $key is of 'mixed' type currently?

You could try casting $key to string type earlier in the foreach loop.

foreach...
$key = (string) $key;

darkdog

RichardAubin That's unfortunately not it. $key is of array-key type, and by the time it reaches the check it's already a string.

JakubMisek

When updated to the Laravel 12.x - I can reproduce the issue as well.

Thank you for pointing this out, and for your help. We'll try to fix it asap.