Emit a warning when type parameters are shadowed.

[hborla]

This code does not produce any diagnostics:

struct S<T> {
  func f<T>(_: T) {}
}

Then, confusing errors are produced when the above code is called incorrectly:

S().f(1) // error: Generic parameter 'T' could not be inferred

This is fundamentally because the type parameter T is shadowed in func f. Usually, programmers do this by accident - they meant for the inner T to match the outer T. The compiler should emit a warning when type parameters are shadowed like this, with two notes for possible fixes:

• A note to remove the shadowed type parameter with a corresponding fix-it.
• A note to rename the shadowed type parameter.

[jumhyn-duolingo]

Is there ever a legitimate case for this shadowing? I.e., do we need a silencing mechanism here, or would it be fine to always require a rename?

[airspeedswift]

I can only think of bad reasons e.g. coming up with different letters or names for the type parameters is annoying

[hborla]

Is there ever a legitimate case for this shadowing?

I have never seen one. There are other issues with shadowing too; for example, shadowed type parameters are busted in Swift interfaces because there's no way to qualify a reference to the outer type parameter in case it shows up in the shadowed scope, e.g. when printing fully qualified nested types with shadowed generic parameters:

protocol P {}

struct Outer<T: P> {
  struct Inner<T> {
    func f() -> Inner<T> {}
  }
}

The fully qualified result of f is Outer<T>.Inner<T>, but in that context, the first T is wrong because it references the shadowed T without any conformance requirement, resulting in a bogus error when rebuilding a module from its Swift interface.

[dfperry5]

Has anyone taken this on? Or is it OK if I give it a shot?

[hborla]

@dfperry5 go for it!

[dfperry5]

I've been moving slow - but planning on diving into this this week!