diff options
author | Martin Odersky <odersky@gmail.com> | 2015-02-13 11:53:09 +0100 |
---|---|---|
committer | Dmitry Petrashko <dmitry.petrashko@gmail.com> | 2015-03-18 11:11:06 +0100 |
commit | 93747cdb576d0a2cb17db1d392e1bdb56e8e6049 (patch) | |
tree | dd28e66e5a9746bde6fbf1963ec653746678cb56 /LICENSE.md | |
parent | 32892db46e66b26e378f765b45983cdac3dec573 (diff) | |
download | dotty-93747cdb576d0a2cb17db1d392e1bdb56e8e6049.tar.gz dotty-93747cdb576d0a2cb17db1d392e1bdb56e8e6049.tar.bz2 dotty-93747cdb576d0a2cb17db1d392e1bdb56e8e6049.zip |
Stop type inference from creating oprphans.
A tweak in the answer to a fundamental question of inference:
When should type variables be instantiated?
Example: In a call
f [ TVar ] ( g() )
A syntehsied type variable TVar can be instantiated as soon
as the call is fully elaborated, but not before - in particular not
when typing the nested call `g()`.
This is so far achieved by looking at the `owningTree` of a type variable
(in the example it would be the call above) and instantiating only if the
current tree contains the owning tree. Problem is that this is fragile.
If in the meantime the tree was copied, say due to eta-expansion, the contains
test will fail. Now this is not a big deal, as long as we instantiate the type
variable eventually. But previously that was never done.
With the fix we now instantiate type variables also if we have fully elaborated
the definition that closest encloses the point where the type variable is created.
This is less fragile, as definitions can be compared using their symbols instead
of looking at trees.
Diffstat (limited to 'LICENSE.md')
0 files changed, 0 insertions, 0 deletions