Interface parameters are not correctly autowired

[ramonacat]

This works correctly on PHP-DI 5, but not on 6:

<?php
require_once __DIR__.'/vendor/autoload.php';
interface A {}
class B implements A {}

class C {
	function __construct(A $a) {}
}
$builder = new DI\ContainerBuilder();
$builder->useAnnotations(false);
$builder->useAutowiring(true);
$container = $builder->build();
$container->set(A::class, \DI\get(B::class));

$c = $container->get(C::class);

var_dump($c);

Is this change of behaviour intended? I haven't found anything about this in the migration guide.

Output of the script on PHP-DI6:

$ php test.php
PHP Fatal error:  Uncaught DI\Definition\Exception\InvalidDefinition: Entry "C" cannot be resolved: Entry "A" cannot be resolved: the class is not instantiable
Full definition:
Object (
    class = #NOT INSTANTIABLE# A
    lazy = false
)
Full definition:
Object (
    class = C
    lazy = false
    __construct(
        $a = get(A)
    )
) in C:\Users\[REDACTED]\Desktop\dupa\vendor\php-di\php-di\src\Definition\Exception\InvalidDefinition.php:18
Stack trace:
#0 C:\Users\[REDACTED]\Desktop\dupa\vendor\php-di\php-di\src\Definition\Resolver\ObjectCreator.php(155): DI\Definition\Exception\InvalidDefinition::create(Object(DI\Definition\ObjectDefinition), 'Entry "C" canno...')
#1 C:\Users\[REDACTED]\Desktop\dupa\vendor\php-di\php-di\src\Definition\Resolver\ObjectCreator.php(71): DI\Definition\Resolver\ObjectCreator->createInstance(Object(DI\Definition\ObjectDefinition), Array)
#2 C:\Users\[REDACTED]\Desktop\dupa\vendor\php-di\php-di\src\Definition\Resolver\ResolverDispatcher.php(64): DI\Definition\Resolver\ObjectCr in C:\Users\[REDACTED]\Desktop\dupa\vendor\php-di\php-di\src\Definition\Exception\InvalidDefinition.php on line 18

composer show:

$ composer show
jeremeamia/SuperClosure 2.4.0  Serialize Closure objects, including their context and binding
nikic/php-parser        v4.0.3 A PHP parser written in PHP
php-di/invoker          2.0.0  Generic and extensible callable invoker
php-di/php-di           6.0.2  The dependency injection container for humans
php-di/phpdoc-reader    2.1.0  PhpDocReader parses @var and @param values in PHP docblocks (supports namespaced cl...
psr/container           1.0.0  Common Container Interface (PHP FIG PSR-11)
symfony/polyfill-php56  v1.9.0 Symfony polyfill backporting some PHP 5.6+ features to lower PHP versions
symfony/polyfill-util   v1.9.0 Symfony utilities for portability of PHP codes

[mnapoli]

Thank you for the bug report.

Do you have caching or compilation enabled? Or is it exactly the code you posted here?

[ramonacat]

The code that I tested is exactly what I posted (and the only dependency in my composer.json was php-di/php-di).

[mnapoli]

OK thanks, then I believe it's a bug. I'll have a look at it! (the test class for context: https://github.com/PHP-DI/PHP-DI/blob/master/tests/IntegrationTest/ContainerSetTest.php#L33)

[ramonacat]

Hey
Did you have a chance to have a closer look at the issue?

[mnapoli]

Unfortunately not sorry :/ What could be great to move forward is if you could send a PR with a new test that reproduces this (I added a link to where that test could be added in my previous comment). Maybe that will help understand the issue.

[smytsyk]

Hey Matthieu,
I have created a pull request with the test:
#621

We have a lot of bindings which are set this way.
Upgrade PHP-DI v5 to v6 is not possible now, because it fails hard. It's really sad, and we even think about other packages to jump on in this case. It will be really appreciated if you could take a look.