Native return type conflicting with parent declaration, while docbloc type with same definition accepted

[Ocramius]

Given following example ( https://psalm.dev/r/e51bdf311a ), psalm seems to infer the incorrect types in EnumField::fromMixedToValue()

<?php

/** @template-covariant TValue of scalar|DateTimeImmutable */
abstract class Field
{
    /** @psalm-return TValue|null */
    abstract public function from(mixed $value): mixed;
}

/** @extends Field<string> */
class EnumField extends Field
{
    public function from(mixed $value): string|null
    {
        if ($value === null) {
            return null;
        }

        return (string) $value;
    }
}

Psalm output (using commit 51838a5): 

ERROR: [InvalidReturnStatement](https://psalm.dev/128) - 19:16 - The inferred type 'string' does not match the declared return type 'null' for EnumField::from

ERROR: [InvalidReturnType](https://psalm.dev/011) - 13:41 - The declared return type 'null' for EnumField::from is incorrect, got 'null|string'
 
Psalm detected 1 [fixable issue(s)](https://psalm.dev/docs/manipulating_code/fixing/)

Adding an /** @return string|null */ solves the issue:

<?php

/** @template-covariant TValue of scalar|DateTimeImmutable */
abstract class Field
{
    /** @psalm-return TValue|null */
    abstract public function from(mixed $value): mixed;
}

/** @extends Field<string> */
class EnumField extends Field
{
    /** @return string|null */
    public function from(mixed $value): string|null
    {
        if ($value === null) {
            return null;
        }

        return (string) $value;
    }
}

Psalm output (using commit 51838a5): 

No issues!

I wonder if type inference is overriding native types here? 🤔

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/e51bdf311a

<?php

/** @template-covariant TValue of scalar|DateTimeImmutable */
abstract class Field
{
    /** @psalm-return TValue|null */
    abstract public function from(mixed $value): mixed;
}

/** @extends Field<string> */
class EnumField extends Field
{
    public function from(mixed $value): string|null
    {
        if ($value === null) {
            return null;
        }

        return (string) $value;
    }
}

Psalm output (using commit 51838a5):

ERROR: InvalidReturnStatement - 19:16 - The inferred type 'string' does not match the declared return type 'null' for EnumField::from

ERROR: InvalidReturnType - 13:41 - The declared return type 'null' for EnumField::from is incorrect, got 'null|string'

[orklah]

I think it's Psalm failing to correctly infer the type of the template when it's redefined in a child class.

The return type of from is (TValue as scalar|DateTimeImmutable)|null in Field. When EnumField inherits Field, from must take the most precise return type (which is still the parent docblock). It should become (TValue as string)|null because EnumFields extends Field<string> but I think it fails to do that and just infers something like never|null which become null.

I'm not sure where this should be fixed though

[Ocramius]

Is there any way this can be reduced further, perhaps? 🤔

We have suspicions, but we don't know what's going on precisely.

/cc @guidobonuzzi

[orklah]

Well, this shows the same thing: https://psalm.dev/r/57e10b684b with every unnecessary thing stripped (and I replaced null with bool just in case)

I really think it's an issue with TValue just being dropped by Psalm's inference.

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/57e10b684b

<?php

/** @template TValue */
abstract class Field
{
    /** @psalm-return TValue|bool */
    abstract public function from(mixed $value): mixed;
}

/** @extends Field<string> */
class EnumField extends Field
{
    public function from(mixed $value): string|bool
    {
        return 'a';
    }
}

Psalm output (using commit d0be59e):

ERROR: InvalidReturnStatement - 15:16 - The inferred type ''a'' does not match the declared return type 'bool' for EnumField::from

ERROR: InvalidReturnType - 13:41 - The declared return type 'bool' for EnumField::from is incorrect, got ''a''

[orklah]

I'm surprised but it seems to have been fixed :)

[danog]

It was thanks to #8926, which fixed a bug I introduced earlier when I improved the intersection logic :)