phptools-docs
phptools-docs copied to clipboard
Support constant enumerations in PHPDoc
In the example below, the * character should be treated as a part of the type (currently it's not even highlighted).
class Foo
{
public const STATUS_OK = 200;
public const STATUS_NOT_FOUND = 404;
public function __construct(
/** @var self::STATUS_* */
private int $status,
) { }
}
PHPStan docs: https://phpstan.org/writing-php-code/phpdoc-types#literals-and-constants. Psalm docs: https://psalm.dev/docs/annotating_code/typing_in_psalm/#specifying-stringint-options-aka-enums.
Thank you for pointing this out.
Even though we parse the PhpStan/Psalm syntax, this is too complex for our analysis engine at the moment. I'll leave this issue open and we'll see in the future.
Even though we parse the PhpStan/Psalm syntax
The syntax highlighting (* being gray) made me think that it's not parsed correctly. Opened #612 for that.
this is too complex for our analysis engine at the moment
Even if this can't be type checked, maybe it could be used to provide better completion? That would be useful too.
@jakubmisek If I understand correctly, currently self::STATUS_* is treated as mixed. Do you think you could add the same treatment to global constants (like LOG_SEVERITY_*) to avoid false positives?
One more seemingly easy improvement would be to respect native type hints, i.e. in case like one below, type of $foo could me int instead of mixed:
/** @param Foo::STATUS_* $foo */
function test(int $foo) {}
@jrmajor
-
Good point. I'll take a look at highlighting (this may be a VSCode issue though)
-
We should already respect the type hint:
Do you have an example where it doesn't work?
When you hover on function call, the param type will be mixed:
@jrmajor I see! thanks
Fixed in the latest update.
The remaining issue is the lack of support for constants in PHPDoc.