DEVSENSE / phptools-docs

PHP Tools public content
Apache License 2.0
77 stars 10 forks source link

Support constant enumerations in PHPDoc #608

Open jrmajor opened 1 month ago

jrmajor commented 1 month ago

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.

jakubmisek commented 1 month ago

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.

jrmajor commented 1 month ago

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.

jrmajor commented 5 days ago

@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) {}
jakubmisek commented 4 days ago

@jrmajor

  1. Good point. I'll take a look at highlighting (this may be a VSCode issue though)

  2. We should already respect the type hint:

    image

Do you have an example where it doesn't work?