diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2013-06-03 09:48:41 +0200 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2013-06-05 16:41:14 +0200 |
commit | 8518709d83b98bed6cac8437c3964e59f2ba5cd6 (patch) | |
tree | e04d17ffb7183dc54140bbbfd5cef9b1623a6470 /test/benchmarking | |
parent | d70c0e344d420af1d8520b0a73109850f66c518c (diff) | |
download | scala-8518709d83b98bed6cac8437c3964e59f2ba5cd6.tar.gz scala-8518709d83b98bed6cac8437c3964e59f2ba5cd6.tar.bz2 scala-8518709d83b98bed6cac8437c3964e59f2ba5cd6.zip |
SI-6308 Specialize methods that have some unspecialized params
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?
Diffstat (limited to 'test/benchmarking')
0 files changed, 0 insertions, 0 deletions