[ConstraintSystem] Introduce a notion of a "hole"

[xedin]

A "hole" is a type variable which type couldn't be determined
due to an inference failure e.g. missing member, ambiguous generic
parameter which hasn't been explicitly specified.

It is used to propagate information about failures and avoid
recording fixes which are a consequence of earlier failures e.g.

func foo<T: BinaryInteger>(_: T) {}

struct S {}

 foo(S.bar) // Actual failure here is that `S` doesn't have a member
            // `bar` but a consequence of that failure is that generic
            // parameter `T` doesn't conform to `BinaryInteger`.

[xedin]

/cc @hborla this could also be used to properly diagnose situations like Optional(.none) when you have encountered, all of the defaulted generic parameters have to be recorded as "holes".

[xedin]

@swift-ci please smoke test

[varungandhi-apple]

Sorry to butt in but can we use some terminology other than "hole" if it's not too late already? In Agda/Idris/Haskell/Scala/Purescript, a "hole" represents "I don't know what term I should write here, but compiler, you know the type of the expression that should appear here, as well as the types of the different terms in scope, so give me suggestions for what term I should write here". Perhaps "invalid type variable" or "illegal type variable"?

[xedin]

@varungandhi-apple It's not actually an invalid or illegal type variable, but the one which solver couldn't infer a type for hence a hole. I believe that this is actually a term used in the type system related papers too, at least ones I saw about diagnostics.

[varungandhi-apple]

@xedin thanks for clarifying! I misunderstood the original comment.

[xedin]

Let's smoke test it once again just in case since it's been a while.

[xedin]

@swift-ci please smoke test