Specialization foiled by cloned type parameters (results of TypeMaps in prior phases) #7559
Description
Residual (and more) of #6308.
See the "todo" tests in t6308.scala.
And then consider:
SpecializeTypes uses symbol equality all over the place, e.g.
specializedTypeVars(sym).intersect(env.keySet)
These break down if the one side of the equality refers to a type parameter symbol from typer, and another refers to one post-uncurry, which has been cloned during a TypeMap. If the type parameter is bound by an alias type, the TypeMap in uncurry is not an identity, so new symbols are allocated.
The easiest way to see what's happening is to remove the code the preserves symbols through identity type maps:
/** Called by mapOver to determine whether the original symbols can
* be returned, or whether they must be cloned.
*/
- protected def noChangeToSymbols(origSyms: List[Symbol]): Boolean = {
- @tailrec def loop(syms: List[Symbol]): Boolean = syms match {
- case Nil => true
- case x :: xs => (x.info eq applyToSymbolInfo(x)) && loop(xs)
- }
- loop(origSyms)
- }
+ protected def noChangeToSymbols(origSyms: List[Symbol]): Boolean = false
And witness the carnage.
/tools/partest-ack specialized
% tests-with-matching-paths ... 20
% tests-with-matching-code ... 115
# 117 tests to run.
...
70/117 passed, 47 failed (elapsed time: 00:00:49)
AFAIK nothing should be relying on noChangeToSymbols for correctness. Maybe @adriaanm or @paulp could confirm that claim.
Specialization isn't unique in this regard; other facets of the compiler have also grown accustomed to type and value parameter symbols being quasi-constant.
I don't really know how to fix this category of problems. I tried pretty hard a while back in uncurry but ran out of steam. Some interaction with caching of normalized types within TypeRefs finally killed off that effort.