[5.4] Fix contextual bindings when instances and aliases are involved

[thecrypticace]

A resubmit of #15637 directed at 5.4.

Ping @taylorotwell, addressing your last comment from the PR:

So if something needs to be contextually built can it ever be bound as an instance after this PR? For example if I want a controller method to have SomeLogger implementation of the Logger interface, and SomeLogger is bound as an instance, will that be respected or will the container create a new instance every time?

Yes. It does respect it. I've added a test to ensure that only one instance of SomeLogger (or in the case of the test ContainerTestContextInjectInstantiations) is created and used during contextual binding if there is an instance available.

I couldn't come up with a better name for ContainerTestContextInjectInstantiations that followed the conventions of the other classes in the test case. Feel free to change it. :)

[taylorotwell]

Didn't I just fix this? Did my commit not fix this problem? I confirmed with your original logger example it was fixed.

[thecrypticace]

I ran the all the tests I wrote a while ago (same ones in the PR) to confirm the problem was fixed and these did not pass:

testContextualBindingWorksForExistingInstancedBindings
testContextualBindingWorksForNewlyInstancedBindings
testContextualBindingWorksOnExistingAliasedInstances
testContextualBindingWorksOnNewAliasedInstances
testContextualBindingWorksOnNewAliasedBindings
testContextualBindingDoesntOverrideNonContextualResolution

[thecrypticace]

The main thing that it needs is skipping the instance short circuit in make()

If I have a contextual binding for IContainerContractStub and IContainerContractStub exists as an instance it immediately returns the instance in the container and not the one given by the contextual binding.

Basically, with the way it works now, a container instance overrides all resolution and returns that one object for every request regardless of the registered contextual bindings.

Does this explanation help at all?

[thecrypticace]

Furthermore, the reason the log code works with what you provided has to do with some of the refactoring.

On 5.3: https://github.com/laravel/framework/blob/5.3/src/Illuminate/Foundation/Bootstrap/ConfigureLogging.php#L41

On 5.4: https://github.com/laravel/framework/blob/master/src/Illuminate/Log/LogServiceProvider.php#L17

On 5.3 it is using instance (which this PR fixes contextual bindings for). On 5.4 it is using singleton (which your commit fixed contextual bindings for). So the problem still exists just not for the logger because the setup changed.

[GrahamCampbell]

Please add phpdoc.

[GrahamCampbell]

Please make this protected, and add phpdoc.

[GrahamCampbell]

Does this work properly if you use the flag on phpunit that lets you run the tests multiple times?

[GrahamCampbell]

If so, why does this variable get initialized here?

[thecrypticace]

It does not work. It's a left over from before I set it in the test itself. Thanks for catching this.

[taylorotwell]

OK Thanks for feedback.