Sema: Arrange TypeCheckType to open unbound generics on the fly

[AnthonyLatsis]

Lays the groundwork for sinking UnboundGenericType to unblock #31895. The idea was put forth by Slava over here. NFC expected, because for now the "opener" is used as intended only where unbound generics were already being handled in-place; the remaining type resolution sites that allow unbound generics to escape are now marked with FIXMEs. With this much we are safe to nuke TypeResolutionFlags::AllowUnboundGenerics and start addressing these FIXMEs incrementally.

[AnthonyLatsis]

@davidungar This change uncovered what looks like an ASTScope expansion bug:

class Outer {
  class Inner {}
}

extension Outer.Inner {
  func foo(arg: Inner) {} // Could not find `Inner` in scope
}

My prints are telling me that name lookup is hopping straight to file scope from the extension. Could you offer me some guidance here? Where exactly is the parent scope decided upon?

[CodaFi]

We oughta make a functor for the no-op case a default argument to both functions.

[AnthonyLatsis]

The no-op is a temporary hack. I figured writing them out explicitly with FIXMEs is a good idea, rather than defaulting the parameter.

[CodaFi]

Another candidate for a default

[CodaFi]

The approach here looks fine, just picking around the edges mostly. We can take the simpler changes to TypeCheckType (removal of dead parameters and such) now if you would like to split them.

[CodaFi]

My prints are telling me that name lookup is hopping straight to file scope from the extension. Could you offer me some guidance here? Where exactly is the parent scope decided upon?

You don't have to worry about that - it's a pre-existing limitation of name lookup in extensions of nested types.

[AnthonyLatsis]

We can take the simpler changes to TypeCheckType (removal of dead parameters and such) now if you would like to split them.

Thanks for taking a look! I was able to remove the isSpecialized parameter by encapsulating and moving generic argument inference out of resolveTypeInContext, but there are still a couple of annoying test failures due to this. Anything else like the removal of a factory constructor on TypeResolution is fairly minor and can wait.

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please test source compatibility release

[AnthonyLatsis]

Alright, this is now ready for review.

[AnthonyLatsis]

@swift-ci please smoke test macOS

[AnthonyLatsis]

@swift-ci please smoke test

[AnthonyLatsis]

@swift-ci please test source compatibility release

[CodaFi]

This looks a lot better, thanks! Let’s see what Slava and Pavel have to say.

[slavapestov]

I think for the underlying type of a type alias, the right way to handle it is to desugar the typealias into a generic one. Eg,

typealias Foo = Array

is really the same as

typealias Foo<Element> = Array<Element>

[slavapestov]

if they're truly invalid, then instead of complaining, we should be ensuring that the TypeResolution's context kind and so on doesn't allow them in the first place.

[AnthonyLatsis]

Perhaps the sentence is flawed. What I meant to convey is that we may want to someday reconsider complaining about unbound generics here (we do complain today). For example:

let foo: [Array<Float>] = [[3], [4], [5]] as [Array] // error

[AnthonyLatsis]

@xedin ping

[slavapestov]

@AnthonyLatsis IMO this is ready to merge.

[AnthonyLatsis]

@slavapestov recd. Needs another rebase though.

[AnthonyLatsis]

@swift-ci please smoke test and merge

[AnthonyLatsis]

@swift-ci please smoke test and merge

[AnthonyLatsis]

@swift-ci please smoke test