[GSB] [Diag] Constraint to concrete type using ":" should offer a fix-it

[theblixguy]

This PR adds a fix-it when constraining to a concrete type using ":".

Example:

struct Foo<Bar> {
  func doSomething() {}
}

// error: type 'Bar' constrained to non-protocol, non-class type 'String'
// fixit: use 'Bar == String' to require 'Bar' to be 'String'
extension Foo where Bar: String {}

Resolves SR-7984.
Resolves rdar://problem/41069420

[theblixguy]

cc @jrose-apple @xedin

[airspeedswift]

@swift-ci please smoke test

[slavapestov]

Sorry to keep nit-picking, we're getting close!

[theblixguy]

@jrose-apple Ah ok, I am thinking about what the best solution would be to handle this scenario. Maybe enforce that the current decl context isn't a protocol (or if it is, then the subject type isn't defined inside the protocol)? Because in this example, the fix-it should be offered:

protocol Foo {
  func S<T : Sequence>(bar: T) where T.Element: String // fix-it for ==
}

but not in this situation:

protocol Foo {
  func foo<T>(bar: T) -> T where T: String // no fixit
  associatedtype Baz: String // no fixit
}

[jrose-apple]

Right, the fix-it can be offered when

• the constraint is on an associated type (as a dependent type, not an AssociatedTypeDecl), OR
• the constraint is on a generic parameter and we're in an extension

[theblixguy]

@jrose-apple Hmm, the subject type ends up being a dependent type, but checking if it has an associated type decl or not seems to work 🎉 Ran the tests again and I think this is good to go.

[slavapestov]

A DependentMemberType having an associated type set does not mean it’s part of an associated type’s inheritance clause.

The “real” way to see if you’re inside an extension or not, or an associated type, etc is to look at the RequirementSource passed in when the constraint was added. @DougGregor can you help explain how this works?

[theblixguy]

@slavapestov Interesting. At the moment, I have a check dependentMemberType && !dependentMemberType->getAssocType(), which seems to work for cases where the previous code was generating the wrong diagnostics.

It seems we can check for source.isExplicit() and then emit the fix-it? Or maybe we need to check for a different FloatingRequirementSource kind. Or maybe we can do source.getSource(*this, subjectType) but I need to look into how to use this to determine the context.

[theblixguy]

@slavapestov I have updated my code to use RequirementSource, does it look good to you?

[jrose-apple]

@swift-ci Please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 45d28aa

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 45d28aa

[theblixguy]

All tests have passed @jrose-apple 🎉

[jrose-apple]

:-) Still waiting on Slava for final review, but it's looking good to me!

[slavapestov]

OK. I still don't completely understand the dependent member type thing, but If source compat passes, I'm happy enough to merge.

[slavapestov]

@swift-ci Please test source compatibility

[theblixguy]

@slavapestov I have updated the code based on @DougGregor's feedback. Could you run the CI again for me? It's only a minor change so not sure if it requires a full test + source compat again.

[jrose-apple]

Drive-by CI

@swift-ci Please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - fd1e248

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - fd1e248

[theblixguy]

Tests have passed 🎉 @jrose-apple @slavapestov

[jrose-apple]

Thank you, @theblixguy!