[VarExporter] fix contravariance problem with __unserialize() in lazy proxy

[nikophil]

Q	A
Branch?	6.4
Bug fix?	yes
New feature?	no
Deprecations?	no
Fix	#57470
License	MIT

LazyProxyTrait::__unserialize() has currently the following prototype: public function __unserialize(array $data): void. So, classes defining this __unserialize() method without the array type hint could not use LazyProxyTrait

Compile Error: Declaration of Symfony\Component\VarExporter\LazyProxyTrait::__unserialize(array $data): void must be compatible with Foo::__unserialize($data)

[derrabus]

Not adding types will cause trouble in other scenarios. We should probably document how to use the trait in untyped codebases.

[nicolas-grekas]

Instead, we could generate the method in ProxyHelper maybe?
Something like

use LazyProxyTrait {
    __unserialize as __doUnserialize;
}

public function __unserialize($data): void { $this->__doUnserialize($data); }

[stof]

wouldn't this cause issues in those other cases mentioned above ? And if no, why not updating the trait directly ?

[nikophil]

Not adding types will cause trouble in other scenarios

as a curiosity, which would be these scenarios?

Instead, we could generate the method in ProxyHelper maybe?

done!

[nicolas-grekas]

why not updating the trait directly ?

for correctness and also to allow child classes to add the type hint I'd say

[nicolas-grekas]

Tests are failing so there are some details to fix but this looks good to me so far, thanks.

[nikophil]

yes, I saw this... any hints about the failure?
It occurs in doctrine bridge tests: variable $service here seems to be a stdClass_c562334 (hence the failure). But I have the same behavior on branch6.4 🤔

[derrabus]

The PR title does not reflect the proposed change anymore though.

[nicolas-grekas]

Thank you @nikophil.