@nicolas-grekas you can imagine that we definitely need tests for that 😄 Where is the application you played with? Which branch is failing without this patch?

Here's a reproducing test case.
Thanks@nicolas-grekas for your time yesterday on this. I was wrong, the service we were playing with were marked asshared = false by a compiler pass. So the bug you encounter by declaring an unshared service is the same.

Service declarations

<serviceid="foo"class="Foo"shared="false">    <callmethod="setFooBar">        <argumenttype="service"id="foo_bar" />    </call></service><serviceid="foo_bar"class="FooBar">    <argumenttype="collection">        <argumenttype="service"id="foo" />    </argument></service>

This will lead to this container service dump (which causes an infinite loop).

<?phpuseSymfony\Component\DependencyInjection\Argument\RewindableGenerator;// This file has been auto-generated by the Symfony Dependency Injection Component for internal use.// Returns the private 'foo_bar' shared service.$a =new \Foo();$a->setFooBar(${($_ =isset($this->services['foo_bar']) ?$this->services['foo_bar'] :$this->load(__DIR__.'/getFooBarService.php')) &&false ?:'_'});return$this->services['foo_bar'] =new \FooBar(array(0 =>$a));

Circular setter injection for shared services works fine in some cases, as the instance is registered in$this->servicesbefore calling the setter on it. But this is not always the case. Here are a few case which break things:

• injecting the service in the constructor of the main service (as done here forfoo_bar), as this requires building the dependency before injecting it in the setter
• using only non-shared services in the cycle (we need a shared service in the cycle to break the instantiation loop)
• using a non-shared service as main service would create weird things (as this instance would not be registered, and so the loop would instantiate it again in the cycle). Note that the first shared service reached in the cycle inherits the restrictions of the "main" service.

What I called "main" services are all the services which can trigger the beginning of the cycle:
Here is what identifies the "main" services of a cycle, for which we have the restriction about not involving its constructor in the cycle:

• all public services (as they can be retrieved throughget)
• all shared services referenced from outside this cycle (as the cycle can start when resolving the reference)

However, we need to be sure we don't break BC for cases working fine.

and this means we should write test covering the working case to, to avoid breaking it

Thanks@stof for your explanation
I got this issue when upgrading from Symfony 3.3 to 3.4.
So currently there is a BC break as I'm not able to upgrade to Symfony 3.4 without adapting the service definitions.

The issue is deeper than anticipated: there are much more cases where we can generate code that loop infinitely.
I just pushed a patch that should fix that, but is missing many tests for now (so not all situations are proven as OK yet.)
I'll finish tomorrow. If you want to have a look meanwhile, that's possible.

@symfony/deciders I merged this PR because it's ready on my side, and it's important to have before 4.0.0, so that I wanted to allow as many ppl as possible to test it, which is easier now.
But any review is still welcomed, I'll respond quickly to any report/comments until tomorrow, before the release.