Problem/Motivation

Something in phpspec/prophecy 1.10.0 makes our tests fail on php7.3

They were passing previously

See https://github.com/phpspec/prophecy/compare/1.9.0...1.10.0
And https://github.com/phpspec/prophecy/pull/446

https://github.com/phpspec/prophecy/pull/446 changed the way that comparison for the default token (ExactValueToken) is done for closures.

With prophecy, when you do this:

$this->prophesize(Some:class)->someMethod($some_argument);

Internally it turns $some_argument into new \Prophecy\Argument\Token\ExactValueToken($some_argument) and then calls \Prophecy\Argument\Token\ExactValueToken::scoreArgument which now returns false if the comparator throws a ComparisonFailure

For closures, the comparator used is \Prophecy\Comparator\ClosureComparator which always throws a ComparisonFailure

Proposed resolution

The fix, is to use the long-form and instead of using the default ExactValueToken, use Argument::is() which maps to \Prophecy\Argument\Token\IdenticalValueToken which just does a straight equality comparison, which is fine for the two closures in the test that are broken.

The code we're calling in core that is failing

$this->decoratedFormState->prepareCallback($unprepared_callback)
      ->willReturn($prepared_callback)
      ->shouldBeCalled();

    $this->assertSame($prepared_callback, $this->formStateDecoratorBase->prepareCallback($unprepared_callback));

Where in this scenario, $unprepared_callback and $prepared_callback is a closure, causing the fail.

We actually expect direct equality here, so we should use Argument::is

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CommentFileSizeAuthor
#3 3101720.patch999 byteslarowlan

Comments

larowlan created an issue. See original summary.

larowlan’s picture

Issue summary: View changes

https://github.com/phpspec/prophecy/pull/446 is the issue that broke it (found with git bisect on prophecy)

larowlan’s picture

Status: Active » Needs review
StatusFileSize
new999 bytes

Opened https://github.com/phpspec/prophecy/pull/456 but I think we can resolve this in a different way.

larowlan’s picture

Issue summary: View changes
kim.pepper’s picture

+1 RTBC if green

eric115’s picture

Status: Needs review » Reviewed & tested by the community

Looks good, marking as RTBC

larowlan’s picture

Title: HEAD broken on php 7.3 - updates required for prophecy 1.10.0 » HEAD broken on - updates required for prophecy 1.10.0
Version: 9.0.x-dev » 8.7.x-dev

This is broken on php 7.2 as well, all the way back to 8.7.x

mstrelan’s picture

For searchability ... this issue fixed the below error in phpunit:

1) Drupal\Tests\Core\Form\FormStateDecoratorBaseTest::testPrepareCallback with data set #2 (Closure Object (...), Closure Object (...))
Failed asserting that null is identical to an object of class "Closure"./var/www/site/web/core/tests/Drupal/Tests/Core/Form/FormStateDecoratorBaseTest.php:1447
alexpott’s picture

Committed and pushed 525a4b9bbb to 9.0.x and 73a1544e26 to 8.9.x. Thanks!

Leaving at rtbc for 8.8.x and 8.7.x backport.

  • alexpott committed 525a4b9 on 9.0.x
    Issue #3101720 by larowlan: HEAD broken on - updates required for...

  • alexpott committed 73a1544 on 8.9.x
    Issue #3101720 by larowlan: HEAD broken on - updates required for...

  • larowlan committed 43d4af0 on 8.7.x authored by alexpott
    Issue #3101720 by larowlan: HEAD broken on - updates required for...
larowlan’s picture

Status: Reviewed & tested by the community » Fixed

c/p to 8.8.x and 8.7.x

  • larowlan committed d99446d on 8.8.x authored by alexpott
    Issue #3101720 by larowlan: HEAD broken on - updates required for...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

xjm’s picture

Why was this backported to 8.7? Under normal circumstances, a commit made to the security branch by normal process will never be released because releases are just created on the top of the last tag. This means no security release would ever have benefited from this fix, and indeed 8.8.1 didn't and the one this week won't.

If you have a reason that there is something that needs to be included in a security release, contact a release manager to ensure a normal patch release gets made against the branch.