TypeResolution: Abolish TypeResolutionStage::Contextual

[AnthonyLatsis]

The correctness issue that lead to this refactoring is an inconsistency in how generic metatypes are resolved in properties that are referenced and declared under a certain kind of same-type constraint:

protocol P {}
struct Foo<T> {
  static var property1: T.Type { T.self }
}
extension Foo where T == P {
  // error: cannot convert return expression of type 'P.Protocol' to return type 'P.Type'
  static var property2: T.Type { property1 } 
}

This is a source-breaking change, since these generic metatypes would no longer resolve to existential metatypes when a same-type constraint binds the 'instance type' type parameter to an existential type, be it a protocol requirement or other member.

---

Extracted from #39492

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please smoke test macOS

[slavapestov]

This looks pretty reasonable, just a few comments I'd like to hear your thoughts on before we merge this.

[slavapestov]

Would it be cleaner if it was an instance member?

[AnthonyLatsis]

Perhaps. The fact that we have to consider passing function objects for opening placeholders and unbound generics just to call applyUnboundGenericArguments, even though it never needs them, was a bit of an eyesore. On the other hand, it interacts with a lot of TypeResolution state, and it is a lot easier to manage on-demand use of the generic environment with an instance member.

[AnthonyLatsis]

On second thought, I have to object here. It does appear to be visually cleaner the instance member way, but the fact that we sometimes pass a contextual parent type to applyUnboundGenericArguments just doesn't play well together with a type resolution stage, now that it cannot be "contextual". It seems to be more about whether we want to check requirements or not, rather than which stage we're on. Looking forward to further thoughts.

[AnthonyLatsis]

@slavapestov Just in case – I'm happy to set this discussion aside.

[slavapestov]

Even if there is a parent type, it might be nested inside of another non-type generic context, eg

func foo<T>() {
  struct Outer {
    struct Inner {
      typealias A = Array<T>
  }
}

[AnthonyLatsis]

IIRC we don't support type declarations nested inside generic (or contextually generic) functions, so it's alright for now.

[AnthonyLatsis]

I've changed the flag name to "isTypeResolution" to be more explicit.

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please test source compatibility release

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please test source compatibility release

[AnthonyLatsis]

@swift-ci please smoke test macOS

[slavapestov]

Only one remaining question.

[slavapestov]

Instead, can you pass a GenericSignature and call getGenericEnvironment() on it when needed?

[AnthonyLatsis]

Ah, great suggestion!

[AnthonyLatsis]

Passing a GenericSignature instead of a function ref results in one more duplicate circularity error in compiler_crashers_2_fixed/0161-sr6569.swift. Do you reckon that sounds fine? All this fuss around checkContextualRequirements() is really only to make sure that is works correctly with SIL code, where we explicitly pass a generic environment to type resolution, because it cannot be derived from context.

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please test source compatibility

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please smoke test