Imported From: https://issues.scala-lang.org/browse/SI-6624?orig=1
Reporter: @retronym
Affected Versions: 2.10.0-RC1
Other Milestones: 2.10.0

@retronym said:

d7f498ac9cccd7473be8f416a1620548ca8fca9b is the first bad commit
commit d7f498ac9cccd7473be8f416a1620548ca8fca9b
Author: Paul Phillips <paulp@improving.org>
Date:   Tue Oct 16 08:07:17 2012 -0700

    Disabled generation of _1, _2, etc. methods.
    
    This was part of the introduction of ProductN, which had
    to go back into pandora's box because of issues with cycles
    during typing.  These should have been reverted along
    with it.

@retronym said (edited on Nov 7, 2012 2:28:10 PM UTC):
The underlying problem, that was masked by having the _N methods around, is that we get a subpattern typed as:

KList[Option] with KCons[Option, ...] . This doesn't have any caseFieldAccessors (that looks in decls, not members), so we fall through:

val accessorsSorted = accessors sortBy indexInCPA
if (accessorsSorted isDefinedAt (i-1)) REF(binder) DOT accessorsSorted(i-1)
else codegen.tupleSel(binder)(i) // this won't type check for case classes, as they do not inherit ProductN

• Is inference of such a RefinedType itself a problem (ie, A with B where A is already a base type of B)?
• Or do we need to allow for this the pattern matcher?

@retronym said:
Here's a low-risk solution.

https://github.com/retronym/scala/compare/ticket/6624

@retronym said:
The old pattern matcher inserts a cast to the "necessary type", which is the type of constructor pattern, rather than the scrutinee. It looks for case field accessors on this, instead.

@retronym said:
So here's an alternative fix in that vein:

https://github.com/retronym/scala/compare/ticket/6624-2

@adriaanm said:
thanks to minimizer and fixer!

I wish I had thought of this when I saw that _1, _2 commit.
I had this sneaky suspicion it would somehow affect this part of the pattern matcher, but couldn't put my finger on it...

I think something along the lines of your second patch would be best.
It is indeed puzzling that we get that refined type.
Maybe we should be using members rather than decls?

I'll have a look

@paulp said:
"Maybe we should be using members rather than decls?"

Is someone holding back an argument for using decls? If not, it should be members.

@retronym said:
I guess back in the day of case class inheritance decls made sense.

@adriaanm said:
The only argument for decls is inertia (and maaaaybe performance).

@adriaanm said (edited on Nov 17, 2012 1:45:34 AM UTC):
well, the other argument is that constrParamAccessors aren't inherited
the relevant difference wrt members is that it deals better with broken types

@paulp said:
Does it matter if the param accessors aren't inherited, when values with the same names are? I guess it matters if the case class fields are private, like in ::, but otherwise... come to think of it the private possibility probably makes it dangerous to think about using members, because

case class A(private var x: Int) { }
class B(q1: Int) extends A(q1) { def x = 123 }

@adriaanm said:
scala/scala#1638

@adriaanm said:
That does matter, I'd say. So we should keep using decls.