[DiagnosticsQoI] Fully Qualify the Parent Type When Diagnosing Missing Member Types

[CodaFi]

Teach the diagnostic engine about a new wrapper type FullyQualified<T>. The intent is to clarify which parameters will be printed with additional qualification in diagnostic text. For now, this is only useful for types, so there's a bit of SFINAE guarding against misuse of the abstraction.

rdar://63199963

[CodaFi]

@swift-ci smoke test

[beccadax]

Nice!

[xedin]

While you are here, what do you think about enabling this by default for generic parameters? It's very common to name generic parameters like T or U which results in diagnostics that say something like "T is not convertible to T" and it would be much better to always qualify it to avoid confusion.

[CodaFi]

I think something like a DescriptiveTypeKind would help out there too.

T is not convertible to generic parameter T

[xedin]

The problem is in most cases we don't know what type we'd get in conversion diagnostics so it'd be better to always qualify generic parameters...

[xedin]

e.g.

protocol P {}
func foo<T: P>(_: T) {}
func bar<T>(t: T) {
  foo(t)
}

This would produce a note which says where 'T' = 'T'

[xedin]

I think it would have been better if it did say where 'T' = generic parameter bar.T or something similar.

[xedin]

Another example with shadowing:

protocol MyProtocol {}

struct Generic<M: MyProtocol> {
    var values: [M] = []

    func valueAt<M>(_ index: Int) -> M? {
        if values.indices.contains(index) {
            return values[index]
        } else {
            return nil
        }
    }
}

Currently results in cannot convert return expression of type 'M' to return type 'M?'

[CodaFi]

Good point. I'll build the abstractions for this in a follow-up.

[xedin]

Sounds great, thank you!

[CodaFi]

@swift-ci smoke test