This ain't hygenic.

case class C2(b: Tuple1[_ <: String])
object C2 {
  class String
}

test/files/run/t6541.scala:28: error: type mismatch;
 found   : (_$1(in method apply),) where type _$1(in method apply) <: C2.String
 required: Tuple1[_ <: String]
case class C2(b: Tuple1[_ <: String])
           ^

Last time I tried to fix this, I ended up with a custom type completer for unapply to add enough laziness to the mix so we could peek at the info of the case class to derive the type of the unapply method.

You are right about hygiene. But note that the error message talks about apply (not unapply), so this failure is not introduced by my change. Arguably, the failure is according to the spec: http://www.scala-lang.org/files/archive/spec/2.11/05-classes-and-objects.html#case-classes.

We should do the same for the parameter types of apply and the return type of unapply: both hygienic, or both not.

We should also include copy in the discussion – it's not systematic that it works differently. The problem with copy is that we have a stronger argument for making it hygienic: otherwise we can get a failure even without an explicit shadowing type declaration:

class A {
  class C
  case class B(x: C) extends A { def copy(x: C = this.x) = ... }
}

The class parameter type is A.this.C. If copy was non-hygienic, the parameter type of copy would be B.this.C (since B extends A), so it would not compile.

Right you are. In fact, the type parameters of copy are also prone to shadowing.

case class C2[T <: String]() {
  class String
}

% scalac-hash v2.11.2 test/files/run/t6541.scala
test/files/run/t6541.scala:28: error: type arguments [T] do not conform to class C2's type parameter bounds [T <: String]
case class C2[T <: String]() {
           ^
one error found

In this case, we can defer that mess to a new ticket and proceed with this one. Perhaps though it needs to be under -Xsource:2.12 as it changes signatures (albeit in a binary compatible way).

I logged https://issues.scala-lang.org/browse/SI-8884

Good point about compatibility, I only thought about binary.

I'm not sure if -Xsource:2.12 is the right solution here, maybe better submit the PR against 2.12? Because the generated pickle is different, so in some sense it's binary incompatible. If you turn it on to compile a library, then a client might fail to compile against the new binary.

I can't see a way that enabling this under -Xsource:2.12 would lead to breakage under separate compilation with different flags. The type of the unapply is computed once and stored in the pickle.

• constrParamss returns duplicated trees

But needn't call it twice (once to determine the method name, and again here).

yep, thanks!