Full variance support if autoloading is used

[nikic]

The first commit moves the loading of the parent class into zend_do_link_class as preparation. The second commit has the main functionality, which works as follows:

• We keep track of the current class linking depth.
• When we encounter an unresolved compatibility check, we remember it as a "compatibility" delayed variance obligation. The compatibility check is not allowed to autoload classes.
• We allow using classes/interfaces in extends/implements that have outstanding variance obligations, but are otherwise fully linked. We remember this as a "dependency" obligation.
• When the linking depth reaches zero, we process the delayed variance obligations. A dependency obligation is satisfied if the dependency is now fully linked. A compatibility obligation is satisfied if the compatibility check passes. Autoloading of new classes is permitted here. If all obligations for a class are satisfied, it is marked as fully linked.
• As new classes may be loaded or become fully linked, we do this until there are no more changes.
• Anything that remains is emitted as a compatibility error/warning.

[nikic]

@dstogov This is my implementation for full variance support with autoloading. It's similar to one of the possibilities we discussed, where we keep track of outstanding obligations and check them later.

This approach should be easy to extend to the non-autoloaded case (if we want to do so). Basically we would have to increment the linking depth before declaring a "group" of classes and then decrementing afterward.

[dstogov]

In my opinion, the behavior implemented by PR is not consistent.
There are possible situation when class can't be used after declaration, because of delayed variance checks.

It looks like, implementation of full variance support in PHP is not possible at all.

I would prefer not to merge inconsistent solutions, and keep only "minimal" variance support (that is restricted by simple rule - parameter classes, that need to be checked, have to be available during class linking).

[dstogov]

This will require extra strtolower() call at run-time.

[nikic]

@dstogov I have now implemented a new version that hopefully resolves the issues we discussed. The core approach is the same as before, with a few differences:

• Delayed variance obligations are processed directly after the class declaration is otherwise done, not when the link depth becomes zero (in fact, link depth is gone now). This means that either the class will link successfully at that time, or there will be an error. There will not be a situation where directly after a class declaration you get a "class not found" error.
• Autoloading of classes is separated into a separate contained step -- I had too much trouble with concurrent modification of datastructures otherwise.
• Because variance is checked earlier, we also need to handle classes in various stages of linking in instanceof. unlinked_instanceof is extended to support this.

One very important conceptual difference is that we do not require the classes used in typehints to be fully linked in order to link a class -- we do ensure that they have correct variance, but don't require full linking. For example, the following example works as expected:

spl_autoload_register(function($class) {
    if ($class === 'A') {
        class A {
            public function method() : B {}
        }
        var_dump(new A);
    } else if ($class == 'B') {
        class B extends A {
            public function method() : C {}
        }
        var_dump(new B);
    } else {
        class C extends B {
        }
        var_dump(new C);
    }
});
var_dump(new C);

In particular the use new B works, even though class C is not fully linked yet at that point. Either C will successfully link lateron, or generate an error. But there is no way to actually use C until that point, or replace it with a different class with incorrect variance.

[nikic]

It would be a good bit more convenient if we could have delayed_obligations as a member of the CE. I didn't put it there because it's only needed during inheritance. If we don't care though, it would simplify code.

[dstogov]

This implementation looks better, but personally, I don't see value for this implementation complication.

I also see ~5% slowdown on ZendFramework benchmark, that just loads most of the ZF classes (this is expected).

[nikic]

Merged as 89b2d88 and 8f8fcbb.