Docblock-defined class, interface or enum named UnitEnum does not exist

[dkarlovi]

Symfony version(s) affected

6.0.5

Description

Updates from 6.0.3 to 6.0.5 and Psalm started reporting issues when using \Symfony\Component\DependencyInjection\Container::getParameter

Docblock-defined class, interface or enum named UnitEnum does not exist (see https://psalm.dev/200)
        $configuredDatabases = $container->getParameter('sigwin_yassg.databases_spec');

How to reproduce

Use 6.0.5 on a Psalm-analyzed app. Wasn't there with 6.0.3.

Possible Solution

Remove the type until 8.1 when only 8.1 is actually supported (6.1?)

Additional Context

No response

[wouterj]

UnitEnum is an enum since PHP 8.1: https://www.php.net/manual/en/class.unitenum.php

Using an undefined class in a return type declaration is valid PHP: https://3v4l.org/SqNEG So I don't understand why Psalm doesn't like it.

Status: works for me I think this can be closed.

[orklah]

Using an undefined class in a return type declaration is valid PHP

Fortunately, Psalm is a tad stricter than PHP. If you make a typo in a class name in a return, I think you'll want Psalm to report it to you so you can fix it.

Additionally, if some PHP 8.0 project has made polyfills (or even used this class name in their project), things will start to get funky in their project.

I completely get why Symfony added UnitEnum there earlier instead of waiting a full PHP 8.1 release, but I find it pretty normal that Psalm emits an error there.

I'll link my answer on both report of this issue that popped up in Psalm repo:
vimeo/psalm#7738 (comment)
vimeo/psalm#7703 (comment)

IMHO, this is something that should be handled by the Symfony Psalm plugin. Checking the version used to perform the analysis to provide stubs with and without UnitEnum (it could be handled directly in Symfony through a specific PHPdoc but the format is not recognized by PHPStan and it's specific enough to be better handled elsewhere)

[derrabus]

I completely get why Symfony added UnitEnum there earlier instead of waiting a full PHP 8.1 release, but I find it pretty normal that Psalm emits an error there.

Yes, it's fair the Psalm emits an error when being run on the Symfony codebase. However, it's at least confusing that Psalm reports an error on a project that happens to use a Symfony component as a dependency. It's nothing that the project could possibly fix. And the line that the error is reported on is perfectly fine.

This error is a false positive.

[derrabus]

Closing as duplicate of #45609

[wouterj]

Fortunately, Psalm is a tad stricter than PHP. If you make a typo in a class name in a return, I think you'll want Psalm to report it to you so you can fix it. [...] I completely get why Symfony added UnitEnum there earlier instead of waiting a full PHP 8.1 release, but I find it pretty normal that Psalm emits an error there.

For the record: I fully agree. It's Psalm's function to be stricter than PHP, to save us hours of debugging time when making simple mistakes that PHP doesn't warn us about. And so I also get the function of this rule, as it'll help discovering typos made in type declarations. Please don't see the few false positives as an attack on Psalm or its maintainers :)

Your stub idea makes sense to me. I'll keep it to reference in future issues like this and anyone being impacted by this notice is welcome to contribute the necessary changes to the Symfony plugin.

Thanks for the input!