I figured out that RemoveEmptyControllerArgumentLocatorsPass could also remove all errored services in non-debug mode, so that we don't generated locators that only contain errored references.

Hi @nicolas-grekas I'm trying to tackle the issue and on the 7.1 branch when trying to reproduce, I'm getting this error right away:

Controller "App\Controller\LuckyController::number" requires that you provide a value for the "$request" argument. Either the argument is nullable and no null value has been provided, no default value has been provided or there is a non-optional argument after this one.

that comes from vendor/symfony/http-kernel/Controller/ArgumentResolver.php:102. I'm not getting an error from ServiceValueResolver.

Could you please post a full trace of the error so I could trace back why it's not happening the same way for me?

I'm doing these steps to reproduce:

symfony new test --webapp
cd test
symfony make:controller hello
# then add Symfony\Component\BrowserKit\Request as argument to HelloController::index()

Going to /hello yields "Cannot autowire argument $request [...]"

@nicolas-grekas I reproduced it, thanks. Now the question regarding this part:

My proposal to fix both issues would be to introduce a special kind of exceptions that ArgumentResolver would use to compute its error message if no other resolver resolved the argument. Then, we would make RequestValueResolver throw this exception when a type ends with Request but has the wrong namespace for example.

Problem is, ServiceValueResolver breaks the chain by throwing an exception whenever it fails to fetch a service, and there is no logic inside ArgumentResolver to handle that, while other resolvers return [] in such cases. So I see two ways:

1. Collect exceptions from resolvers inside ArgumentResolver and then use them to somehow compute a final exception (maybe using exceptions chain). But then there is no consistency - some resolvers return [], some throw an exception.
2. Fix ServiceValueResolver so instead of throwing a RuntimeException, it returns an empty array as the rest of the resolvers, but then make so ArgumentResolver throws a RuntimeException with the same message by default, with a special case for Request arguments.

I personally prefer second way but I may lack context since it's my first contribution.

You've go it right. The first way is basically what I describe in this PR so that's my preference. It improves things by providing a way for resolvers to give more accurate feedback in case an argument could not be found but a resolver "thought" it was still the one targeted.

@nicolas-grekas Awesome! I will follow the first way then. Quick question - in a hypothetical case when multiple resolvers throw an exception, is there a preferred way how to combine them in a single one?

Not exactly, maybe a list with an intro saying "Here are some possible hints:". We'll see :)

@nicolas-grekas I've created a PR. The error will look like this:

Let me know if you prefer another format 👍