diff options
author | Adriaan Moors <adriaan.moors@typesafe.com> | 2016-03-21 21:54:48 -0700 |
---|---|---|
committer | Adriaan Moors <adriaan.moors@typesafe.com> | 2016-03-26 22:55:02 -0700 |
commit | 878e20a5243383300d3b4990146d260409bf5dfd (patch) | |
tree | d7ed82ebf6d317ae901cc5e2317ac6029970a5da /src/library/rootdoc.txt | |
parent | 391e2843f420bb4686b974b18ac361c9bb49465c (diff) | |
download | scala-878e20a5243383300d3b4990146d260409bf5dfd.tar.gz scala-878e20a5243383300d3b4990146d260409bf5dfd.tar.bz2 scala-878e20a5243383300d3b4990146d260409bf5dfd.zip |
Track Function's SAM symbol & target type using an attachment
We cannot use the expected type to track whether a Function node
targets a SAM type, as the expected type may be erased (see test
for an example).
Thus, the type checker attaches a SAMFunction attachment to a
Function node when SAM conversion is performed in adapt. Ideally,
we'd move to Dotty's Closure AST, but that will need a
deprecation cycle.
Thanks to Jason for catching my mistake, suggesting the fix and
providing the test.
Both the sam method symbol and sam target type must be tracked,
as their relationship can be complicated (due to inheritance).
For example, the sam method could be defined in a superclass (T)
of the Function's target type (U).
```
trait T { def foo(a: Any): Any }
trait U extends T { def apply = ??? }
(((x: Any) => x) : U).foo("")
```
This removes some of the duplication in deriving the sam method
from the expected type, but some grossness (see TODO) remains.
Diffstat (limited to 'src/library/rootdoc.txt')
0 files changed, 0 insertions, 0 deletions