Don't resolve a generic type parameter type from null environments

[bitjammer]

The generic environment of a GenericTypeToArchetypeResolver may be
nullptr, as returned by DeclContext::getGenericEnvironmentOfContext,
during prechecking of closure expressions at the necessarily non-generic
top level.

Fixes a couple of crashers.

rdar://problem/28822213

[bitjammer]

@swift-ci Smoke test and merge

[slavapestov]

We should instead figure out why he environment is null.

[DougGregor]

I have this same hack in my tree thats working to remove the partial generic-to-archetype resolver, which has a similar defensive check already.

[bitjammer]

TypeCheckConstraints.cpp:940 says:

  GenericTypeToArchetypeResolver resolver(
      closure->getGenericEnvironmentOfContext());

DeclContext::getGenericEnvironmentOfContext can return nullptr if the closure's context is a module, file, or top level code. Maybe the hack was returning nullptr in the first place, don't you think? I don't think it's a bad thing to add a nullptr check if that's what we're going to use to represent an empty environment ...

[akyrtzi]

I suggest reverting this so we can remember to fix the name lookup issues later.

I don't think this is a good idea, leave an easily reproducible crasher in the compiler for who knows how long (e.g. take a look at how many test cases remain unfixed in validation-test/compiler_crashers). Also see Doug's 6c7277b which is in the defensive spirit.

I think a better approach is to keep defensive checks that prevent crashers and open a JIRA bug to keep track investigating why something is not quite as we expected it to. If this investigation leads to not needing the defensive check then we could remove it as part of that JIRA fix.

For this I opened https://bugs.swift.org/browse/SR-3348

[slavapestov]

@bitjammer A closure at module scope does not have a generic environment. The problem is that name lookup should not be finding the generic parameter in the first place in this case.