The principle:

• Let AutowirePass makes his stuff and logs in an array parameters not found for autowire reference.
• Browse the array above to try a second time cause all the service have been analysed ,created by AutowirePass
• If the array still have values, it really means there is a problem

Unit test fails. I will check why but normally, this proposing code has no effect on the existing behavior and fix the problem announced in the issue.

WDYT ?

@dunglas , WDYT about#22162 and this PR ? not sure it's the right way to take or if it's really useful to do it

Not having any test covering this issue makes it impossible to accept this PR

@stof , right. will fix quickly

this should be done (and discussed) on 2.8 first

@nicolas-grekas,@stof , rebase to 2.8 done.
Test unit pass + 2 tests cases of the current issue#22162 added in test unit pass.

First Point:
Development of the method getPriorityToInstantiableParameters. put a priority order to instantiable parameters. With this, you can create a service autowired like this

service_test:class:MyClassautowire:true

class MyClass {publicfunction__construct(InterfaceRepoInterface$RI,Repo$R)}class Repoimplements RepoInterface {}

It treats$R before$RI so it create the autowire service Repo and can deal the parameter$RI

Second Point:
To deal the problem of service definition order discussed in#22162
I created an array of failed checking parameters definitions.
I make a second pass in the process function to make sure that the service has not been created after. If the second pass fails, I throw an exception as before

Tell me WDYT

I think we should be stricter here andnot turn auto-registered services into type-candidates.
See#22254 for such a proposal.

Closing in favor of#22254