gen_stub.php: Allowed the use of formats like @param array<>

[SakiTakamachi]

This doesn’t change any output, but it makes it easier to provide hints for PHPStan or IDEs.

[DanielEScherzer]

Do you have an example where this would be used?

[SakiTakamachi]

@DanielEScherzer

No, it doesn’t seem necessary for the current code.
I noticed this while creating a prototype for a method that might be proposed as a new addition.
Do you think it’s better not to add it yet?

[DanielEScherzer]

I was just wondering what that prototype was, in case it could be accomplished with the existing support

[SakiTakamachi]

@DanielEScherzer

Ah, I see.
It’s array<mixed, Number|string|int>.

[DanielEScherzer]

That is definitely already possible for return values, e.g.

php-src/ext/standard/basic_functions.stub.php

Line 1546 in d6fc743

* @return array<int|string, int|string|array>

And from what I can see the @param and @return parsing have the same logic

What error are you getting if you try @param array<mixed, Number|string|int> $foo now?
What about @param array<string|int, Number|string|int> $foo ?

[SakiTakamachi]

@DanielEScherzer

The exception I am encountering is this one:

php-src/build/gen_stub.php

Line 4538 in d6fc743

throw new Exception("@$this->name doesn't contain a variable name or has an invalid format \"$value\"");

And from what I can see the @param and @return parsing have the same logic

No, different regular expressions are used for param and return.

edit: Sorry, that might not be correct ↑

edit2: Understood. This method is probably not used for return.

php-src/build/gen_stub.php

Line 4682 in d6fc743

case 'param':

In param, if <> follows array, it fails to extract the variable name.

php-src/build/gen_stub.php

Line 4530 in d6fc743

if ($this->name === "param") {

[DanielEScherzer]

Ah, okay, so the type gets extracted, but not the name? Then this patch makes sense to me, but I'll leave final approval for @kocsismate

[kocsismate]

The original rationale behind the current behavior is that stubs should contain type info that is directly consumed by php-src or php-doc. That's why return types can contain detailed array shape type doc because the optimizer uses the information.

Later on, this was slightly changed. I think Bob made some extended syntax possible (see the comment above the changed code). So I'm approving the changes.