Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SI-8280 regression in implicit selection. #3524

Merged
merged 1 commit into from Feb 14, 2014
Merged

SI-8280 regression in implicit selection. #3524

merged 1 commit into from Feb 14, 2014

Conversation

paulp
Copy link
Contributor

@paulp paulp commented Feb 13, 2014

In 2fa2db7 I fixed a bug where applicable implicit conversions
would not be found for numeric types if one introduced any aliasing
or singleton types, for the usual reasons involving the absence of
uniform type normalization. See pos/t7228 for examples - that test
case has 20 errors in 2.10.3 but compiles in master.

An unintended side effect was making implicit search less oblivious.
It turns out that in so doing I had created ambiguity where there was
none before. Not because it was any more ambiguous, but because the
compiler now had the wits to notice the ambiguity at an earlier time.

The fix for this is not intuitive. The way the internal logic is,
we need to keep the wool over implicit search's eyes, which leads
to those unrecognized types being passed to adapt, where they are
recognized and weak subtyping suffices to be more specific. It is
sufficient for SI-7228 that weak subtyping be done correctly - the
other change, which is reverted here, was exposing the type arguments
of Function1 when a view exists as a subtype of Function1.

It is also possible this could be remedied by calling weak_<:<
somewhere which is presently <:<, but I don't know where and it
has a far greater chance of affecting something else than does
this, which is a straight reversion of a post-2.10.3 change.

In 2fa2db7 I fixed a bug where applicable implicit conversions
would not be found for numeric types if one introduced any aliasing
or singleton types, for the usual reasons involving the absence of
uniform type normalization. See pos/t7228 for examples - that test
case has 20 errors in 2.10.3 but compiles in master.

An unintended side effect was making implicit search less oblivious.
It turns out that in so doing I had created ambiguity where there was
none before. Not because it was any more ambiguous, but because the
compiler now had the wits to notice the ambiguity at an earlier time.

The fix for this is not intuitive. The way the internal logic is,
we need to keep the wool over implicit search's eyes, which leads
to those unrecognized types being passed to adapt, where they are
recognized and weak subtyping suffices to be more specific. It is
sufficient for SI-7228 that weak subtyping be done correctly - the
other change, which is reverted here, was exposing the type arguments
of Function1 when a view exists as a subtype of Function1.

It is also possible this could be remedied by calling weak_<:<
somewhere which is presently <:<, but I don't know where and it
has a far greater chance of affecting something else than does
this, which is a straight reversion of a post-2.10.3 change.
@paulp
Copy link
Contributor Author

paulp commented Feb 13, 2014

Review @adriaanm

paulp referenced this pull request in ReifyIt/basis Feb 13, 2014
@adriaanm adriaanm self-assigned this Feb 13, 2014
@adriaanm
Copy link
Contributor

LGTM, wooly (as in hairy) stuff

adriaanm added a commit that referenced this pull request Feb 14, 2014
SI-8280 regression in implicit selection.
@adriaanm adriaanm merged commit aa2f4a6 into scala:master Feb 14, 2014
@paulp paulp deleted the pr/8280 branch February 14, 2014 01:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants