Description

Running container:lint when a service uses #[Autoconfigure(binds: ['$myDependency' => {...})] raises an error :

[ERROR] A binding is configured for an argument named "$myDependency" under         
         "_instanceof" in file  "/{...}/MyService.php", but no    
         corresponding argument has been found. It may be unused and should be  
         removed, or it may have a typo.

How to reproduce

Given a service

#[Autoconfigure(bind: ['$myDependency' => '@app.my_dependency'])]
class MyService
{
    public function __construct(MyDependency $myDependency)
    {
    }
}

@app.my_dependency is correctly injected into MyService. But when running container:lint with the container dumped (App_KernelDevDebugContainer.xml is present and up to date), it raises an error.

This only happens with #[Autoconfigure]. A similar configuration but using services.yaml works as expected :

__instanceof:
    App\MyService:
        binds:
            $myDependency: '@app.my_dependency'

Explanation of the issue

1. RegisterAutoconfigureAttributesPass parses the #[Autoconfigure] and registers its binding.
2. ResolveBindingsPass reads the binding and uses it to configure the service arguments.
3. The container is dumped, with App_KernelDevDebugContainer.xml containing

   <service id="App\MyService" class="App\MyService" autowire="true" autoconfigure="true">
     <argument type="service" id="app.my_dependency"/>
   </service>

4. ContainerLintCommand then creates a container from the dump.
5. The container is compiled. Since Kernel::initializeBundles() is not called, only the base passes are used.
6. RegisterAutoconfigureAttributesPass parses the #[Autoconfigure] and registers its binding, again.
7. ResolveBindingsPass sees that the service already has an argument (from the xml dump from the first ResolveBindingsPass). This mean that the binding is not used this time, and it is never removed from $unusedBindings.
8. The error is then thrown.

Explanation of the fix

This fix removes the passes that already processed the dumped container.
A more future proof fix would be 209516b, but it would require changes to DependencyInjection.

Both fixes have been tested on a mid size Symfony application.