I still want to see my comments in #27037 as I don't think this code should exist in the PHPUnit bridge at all (the new TestContainer should not be using any deprecated API)

@stof, the new TestContainer is not using deprecated APIs. The reason this was introduced to PhpUnitBridge was because of the following scenario:

4.0 made it impossible to fetch private services from the container. 4.1 then introduced the new TestContainer that allows us to fetch private services from the container within tests (thanks to the new TestContainer). If we are running 3.4 code, and want to make our code 4.x compliant, we start using PhpUnitBridge to weed out the deprecations. We clean up all of the issue in our non-test code where we were getting private services from the container by using proper Dependency Injection and autowiring. However, our tests are still throw warnings about accessing private services from the container within the tests themselves. However, we know that we actually can do this as of 4.1. We don't need to refactor our test code, as the warnings would suggest. So instead, as @nicolas-grekas suggested, we decided to silence these specific warnings when thrown from contexts where private services are access from within tests.

Maybe @nicolas-grekas will be able to explain better than me.

@stof here is how to get this situation:

composer create-project symfony/skeleton:3.4 demo
cd demo
composer req test

This will install symfony/phpunit-bridge 4.*-stable (see symfony/test-pack#3)

That's why I think this is correct and should be supported.

From @stof

depending on how you access the container in the tests, you might get the special test container or the normal one in 4.1

this is correct: if one does $kernel->getContainer()->get('private_something'), the deprecation is valid and this will fail in 4.1 also. On the contrary, $client->getContainer()->get('private_something') works in 4.1 since the container returned by the client is the "test" one.

We have a choice to do: either favor the false positive deprecation (ie revert this altogether) or merge this PR and live with the fact that some tests might break in 4.1.

I'm mixed here, both have advantages... (and I think we cannot be more accurate than done here, unfortunately.)

we indeed cannot be more accurate without changes to the 3.4 WebTestCase, as there is currently no difference between the 2 Container::get calls in the stacktrace.

Reporting deprecation properly would require having $client->getContainer() returning a special container for which we can skip the deprecation.

We'll @stof, that's a very valid and good point. Since both of our two options outlines by @nicolas-grekas are imperfect, I suppose I'm actually in support of undoing #27037, as the code is clearly confusing the community. Hopefully users moving through 4.x deprecation in preperation for an upgrade pay close attention to the documentation and discern that they will be able to ignore certain instances of this deprecation. That is, unless we can touch the 3.4 branch to change the deprecation error to be more specific in regards to the 4.1 TestContainer implementation. But its too late to push this type of change to the 3.4 branch, isn't it?

Thank you for your understanding, I share this opinion. Yes, too late for 3.4.