Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Serializer] TypeResolver update breaks when non-collection generics are used #49924

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
schodemeiss opened this issue Apr 4, 2023 · 3 comments

Comments

@schodemeiss
Copy link

schodemeiss commented Apr 4, 2023

Symfony version(s) affected

6.2.8

Description

Since removing the TypeResolver 1.7 restriction in this commit, I'm getting serialisation errors when classes have docblocks that are not collections.

For example, if I use Psalms "value-of" docblock, the Serializer thinks this is an array of Type, but in reality it's just a string.

How to reproduce

final class StatusClass
{
    final public const STATUS_VALUES = ['accept', 'reject'];

    /**
     * @param value-of<self::STATUS_VALUES> $status
     */
    public function __construct(
        public readonly string $status,
    ) {
    }
}

Attempt to serialise data that looks a little like this and you'll receive an error that $status is an "array".

Possible Solution

  1. Replace in user-land code @param with @psalm-param. Psalm still understands the type, but the serializer doesn't.

  2. Re-add the composer restriction until this issue in TypeResolver is resolved: Generics are always considered as Collection phpDocumentor/TypeResolver#180

Additional Context

No response

@carsonbot
Copy link

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

@schodemeiss
Copy link
Author

Hey, thanks for your report! There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Yes, still happening today on any version of the Serializer.

@mtarld
Copy link
Contributor

mtarld commented Dec 19, 2023

Hey!
I think this is the same issue as #41996.

The PR #52699 may fix it.

fabpot added a commit that referenced this issue Jun 9, 2024
…rface generics (mtarld)

This PR was merged into the 5.4 branch.

Discussion
----------

[Serializer] [PropertyAccessor] Ignore non-collection interface generics

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix #41996 #49924
| License       | MIT

`PhpDocExtractor` and `PhpStanDocExtractor` are following an old version of PSR-5 with used to define collections as the following:
```
generic = collection-type "<" [type-expression "," *SP] type-expression ">"
```
But, it does conflict with non-collection generics.

This issue will automatically be solved if the `TypeInfo` is merged in Symfony. But for older versions (<7.1 at least), it needs a fix.

~I was not able to find a proper bug fix without introducing a BC break, so this PR proposes to opt-on the "non-collection generics" parsing, such as `stcClass<int>` for example.~

~To opt-out from parsing these generics, it'll be required to set `ignore_docblock_generics` in the context. And this key/value will become obsolete as soon as the `TypeInfo` is introduced.~

~I'm not sure how to proceed though, should we only merge it in 5.4, and 6.3 supposing that the `TypeInfo` might be merged in 7.x? Should we document it only in these branches?~

EDIT: I finally ignored PHPDoc generics that aren't well known collection generic types so that the process will fall back to other resolvers (such as reflection resolver for example)

Commits
-------

e31aeeb [PropertyAccessor] Fix unexpected collection when generics
@fabpot fabpot closed this as completed Jun 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants