Skip to content

Covariant Returns and Contravariant Parameters #3712

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
wants to merge 20 commits into from

Conversation

morrisonlevi
Copy link
Contributor

This is the preliminary implementation for this RFC: Covariant Returns and Contravariant Parameters. Opened per Dmitry's request for inline comments on the code.

Copy link
Member

@dstogov dstogov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The full code review will take a while.
The main problem, that the patch doesn't work with opcache yet.

function initialize($properties = array())
{
parent::initialize($properties);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose, you removed this, because of some compatibility break, but you didn't reflect this in RFC.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this comment on bugs.php.net:

Did the unused initialize methods have some bearing on this bug?
Since A does not have a parent it would fatal if it were ever called. I'm adding compile-time warnings to uses of parent when there isn't one and ran across this bug, but since it's "fixed" I can't tell if removing the unused methods has any bearing.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just don't make unrelated "improvements" in PHPT tests, because they look suspicious, and require reviewers to verify them. Better, commit these chunks separately.

Copy link
Contributor Author

@morrisonlevi morrisonlevi Dec 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not unrelated. The unused method A::initialize has erroneous parent:: usage, which this includes. I know you said you would have preferred that to be a different patch, but the code that deals with parent is needed for resolving variance correctly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to add compile-time warning. This would clearly explain the change in behavior, and its correctness.

Fatal error: parent::class cannot be used for compile-time class name resolution in %s on line %d
Deprecated: Cannot use "parent" without a parent class in %s on line %d

Fatal error: Cannot use "parent" without a parent class in %s on line %d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I would separate parent::class into a different patch.

}
/* }}} */

static zend_bool zend_do_perform_implementation_check(const zend_function *fe, const zend_function *proto) /* {{{ */
static int zend_do_perform_implementation_check(const zend_function *fe, const zend_function *proto) /* {{{ */
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is wrong with zend_bool?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See this comment:

This int return is not a boolean, but will often be treated this way.

  • 0 means there is definitely an error.
  • 1 means there are definitely not any errors.
  • -1 means there are no known errors but it is not known to be good either (there is not enough information at the moment).

I am thinking about using an enum here, something like:

typedef enum {
	INHERITANCE_INDETERMINANT = -1,
	INHERITANCE_ERROR = 0,
	INHERITANCE_SUCCESS = 1,
} _inheritance_status;

@morrisonlevi
Copy link
Contributor Author

morrisonlevi commented Dec 21, 2018

The main problem, that the patch doesn't work with opcache yet.

What doesn't work with opcache? I ran some small tests by hand with opcache enabled and it seemed to work as expected.

Edit: I saw your post on the mailing list. I will investigate.

todo: add runtime support when ce cannot be found
Still need to collect and then generate ZEND_VERIFY_VARIANCE opcodes
Known issues:
  - When there is an inheritance warning it gets generated twice.
  - The VERIFY_VARIANCE opcode is not generated in the correct place
Refactor a bit of variance verification compilation.
Fixes this under opcache:

class A {
  function m(Traversable $z) {}
}

class B extends A {
  function m(iterable $z) {}
}

Also fixes cases where A::m is Iterator, IteratorAggregate, etc.
Fixes this under opcache:

class A {
  function m(): iterable {}
}

class B extends A {
  function m(): Traversable {}
}

Also fixes cases where B::m is Iterator, IteratorAggregate, etc.
opcache.enable_cli=1
opcache.optimization_level=-1
--SKIPIF--
<?php if (!extension_loaded('Zend OPcache') || php_sapi_name() != "cli") die("skip CLI only"); ?>
Copy link
Contributor

@carusogabriel carusogabriel Dec 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Off topic: The second part of this condition, when does it happen? I mean, can we run the tests without been via the CLI?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carusogabriel run-tests can actually execute with php-cgi aswell, see: https://github.com/php/php-src/blob/master/run-tests.php#L123 and below and below :)

@morrisonlevi
Copy link
Contributor Author

The build is passing now.

@nikic
Copy link
Member

nikic commented Jan 4, 2019

Can you please rebase this PR to get rid of the parent related changes?

@morrisonlevi
Copy link
Contributor Author

Closing in favor of PR #3732.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants