Symfony 6 adds static return type hinting and Prophecy fails on it. The error message is:
PHP Fatal error: '\static' is an invalid class name in /var/www/html/drupal/vendor/phpspec/prophecy/src/Prophecy/Doubler/Generator/ClassCreator.php(49) : eval()'d code on line 8
See the testbot result from the patch from #3161889-198: [META] Symfony 6 compatibility.
We can wait for a new release of phpspec/prophecy with the fix for this problem. Only the bug is not yet fixed and we want to start with Symfony 6 on the D10.0.x ASAP. Instead of waiting for a fix and a new release, we can also change the testing for the code that gets static return type hinting from Prophecy to mocking. See: https://github.com/phpspec/prophecy/issues/527.
TBD
None
None
None
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3250442-2.patch | 2.03 KB | daffie |
Comments
Comment #2
daffie commentedThe fix.
Comment #3
andypostdoes it mean that prophecy (mocking) may hit us other tests too?
The fix looks valid, please elaborate if it makes sense to stop using prophecy in contrib/custom tests
Comment #4
andypostOr it's only specific to RequestContext?
Comment #5
daffie commentedThe problem is when you are using the return type hint "static" and use Prophecy in testing on that code. You will get the error message from the IS. There is an issue for getting this bug fixed. The problem is that the bug is not fixed at the moment and we cannot start with Symfony 6 in the 10.0.x branch. My idea was to change the use of prophecy to mocking. In that way we can start with Symfony 6 in D10. A kind of quick fix. You can do the same in contrib/custom when you have the same problem and cannot wait until the problem is fixed in Prophecy. See: https://github.com/phpspec/prophecy/issues/527.
Edit: With this change the testbot is green for 9.4.x with Symfony 5.4. No other changes are necessary for core on this problem. See: #3161889-204: [META] Symfony 6 compatibility.
Comment #6
andypostThank you, the patch makes sense ATM (while no fix for prophecy)
Comment #7
longwave+1 to the fix, sometimes having two entirely separate object mocking frameworks available to us is a feature rather than a bug :)
Comment #9
catchCommitted/pushed to 9.4.x, thanks!