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: MyClass
    autowire: true

class MyClass {
  public function __construct(Interface RepoInterface $RI, Repo $R)
}
class Repo implements 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 and not turn auto-registered services into type-candidates.
See #22254 for such a proposal.

Closing in favor of #22254