Add return types to internal methods

[kocsismate]

RFC: https://wiki.php.net/rfc/internal_method_return_types

[nikic]

This probably also needs some adjustments inside opcache to not make use of "optional" return type information, for cases that are subject to inheritance.

[kocsismate]

This probably also needs some adjustments inside opcache to not make use of "optional" return type information, for cases that are subject to inheritance.

Yeah, this was my assumption as well :) But I wanted to defer additional work until we decide what the preferable direction is to go.

[kocsismate]

The word "optional" in the code sounds very bad, so I want to change it to something meaningful... Would be "tentative" a more suitable term?

This probably also needs some adjustments inside opcache to not make use of "optional" return type information, for cases that are subject to inheritance.

How is it possible that no opcache/jit tests fail, even though I have not addressed the possible issues with return type information? UPDATE: because only ext/date method return types were updated.

[kocsismate]

In my recent push, I tried to tidy my commits up, so that hopefully they became easier to review. Besides, I also tried to cater to OPcache and JIT... I'm not really sure if I left out anything..

However, as far as normal behavior is concerned, the PR should be ready for review, since the implementation seems to be done. My only problem is that I'm sure there are some tentative return types which are not really compatible with each other, so they should be found - and possibly fixed or excluded via @no-generate-tentative-return-type - ASAP. I.e. FilesystemIterator::key() and DirectoryIterator::key() is not compatible as currently declared.

[nikic]

In terms of general approach, I don't like the fact that this is picking up types from phpdoc and using them as tentative return types automatically. This makes it hard to see the actual impact, and may be problematic for extensions (if they regenerate their stubs, they'll probably become PHP-8.1-only.)

I think the way this should work is that tentative return types are added as real return types, and the "tentativeness" is indicated through a @tentative-return-type tag or #[TentativeReturnType] attribute. This will allow us to at least see what is actually changing, and it's worth noting that return types will have to be transferred to the position of "real" return types for PHP 9 anyway, so we might as well do it now. This should also allow this change to be split into two parts: One that implements the actual technical change and adds the tentative types to some sample class that is sufficient for testing. And one that actually adds it on a large scale.

[kocsismate]

I understand your concerns, and I have to agree that your suggestion should be the way forward (even though I'll have quite a bit of extra work) :) That said, I'll separate this PR into two new ones.

[kocsismate]

I'm closing this in favor of the new, separated PRs.