Hmm would be nice if the deprecation would tell us which code is triggering this edge-case.

Side note, the deprecation could be optimized by passing $type only once by using %1$s twice.

@javiereguiluz I think this is related to the autowiring of controller arguments (where you might have a typehint for a Post relying on param converters). As there is no autowirable service for this typehint, the AutowirePass triggers the BC layer to try finding one such service by type.

@stof you are right! We use Post as a "param converter" in lots of controllers like this one:

public function showAction(Post $post): Response

Could this be considered a bug? We want to use Post as a param converter, not as a service injection.

Pretty much anything could be added as arguments there via the new controller arguments event and argument value resolvers. Besides of this, pretty much anything that's being set in the request object can be injected this way, not sure if you can catch all those cases.

This process is carried out in RegisterControllerArgumentLocatorsPass, is there a way to know all the excluded resources there? could we verify it to omit these cases?

@yceruto no, you can't know this as a lot of things are resolved during run-time execution. You can only know if they are available as service or not.

Edit: This is why I don't like services as action arguments.

So if we have explicit configuration that excludes resources:

App\:
    resource: '../src/*'
    exclude: '../src/{Entity,Repository,Tests}' # <------

we can't use this information into *Pass to avoid auto-registration of controller typed arguments that aren't available as service?

<service id="autowired.App\Entity\Post" class="App\Entity\Post" public="false" autowire="true"/>

this service is defined at compilation-time, so I hope there is some solution for that.

So this is one of the big reasons that we removed the auto-registration of services for autowiring in 4.0. So in 4.0, it’s not an issue - the entities are excluded in services.yml, and then are not auto-registered during autowiring.

But yes, the deprecation warning is a problem - a bug that we need to fix somehow.

This is basically fixed with #24671 when enabled, isn't it?

#24671 solves this problem for me.