summaryrefslogtreecommitdiff
path: root/test/files/run/t6308.check
Commit message (Collapse)AuthorAgeFilesLines
* SI-6308 Specialize methods that have some unspecialized paramsJason Zaugg2013-06-051-0/+16
This is a continuation of 1591c14e50, which didn't go far enough to handle method calls with a mix of specialized and unspecialized type parameters. This commit modifies `specSym` to calculate the residual type of the original method after specialized type parameters have been removed and the type environment of the candidate specialized variant has been subsituted. For example, here is trace of `specSym` when searcing for the specialized variant of `f4` in the enclosed test: tree = Main.this.f4[Nothing, Int] tree.tpe = (a: Int, b: List[(Int, Nothing)])String fun.tpe = [B, A](a: A, b: List[(A, B)])String residualTreeType = [B](a: Int, b: List[(Int, B)])String memberType = [B](a: Int, b: List[(Int, B)])String env = Map(type A -> Int) doesConform = true A few "todo" tests are included that highlight an endemic issue with the current specialization implementation: type parameters that show up after `uncurry` might be clones of the original symbols from typer, if they have been through a TypeMap (e.g. within a call to `uncurryTreeType`). So testing them for existence with the `typeEnv` map is fruitless. No amount of `atPhase` acrobatics can rescue us from this; we need to transport this information in a symbol-cloning resiliant manner. Maybe Symbol Attachments?