Skip to content

Compatibility issue with Scala at runtime #6450

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

Closed
newca12 opened this issue May 4, 2019 · 4 comments
Closed

Compatibility issue with Scala at runtime #6450

newca12 opened this issue May 4, 2019 · 4 comments

Comments

@newca12
Copy link
Contributor

newca12 commented May 4, 2019

This was initially reported on the dotty gitter channel by @Jasper-M but I did not find an open issue for that.
The behaviour is the same with -language:Scala2

Scala

scala> class Foo { def A(i: Double) = i; object A{ def apply(i: Int) = i+1 }; def foo = A(0) }
defined class Foo

scala> new Foo().foo
res6: Int = 1

Dotty

scala> class Foo { def A(i: Double) = i; object A{ def apply(i: Int) = i+1 }; def foo = A(0) }
// defined class Foo

scala> new Foo().foo
val res0: Double = 0.0
@anatoliykmetyuk
Copy link
Contributor

I believe this is a duplicate of #5074. What do you think @smarter?

@anatoliykmetyuk
Copy link
Contributor

@newca12 does it reproduce outside the repl?

@newca12
Copy link
Contributor Author

newca12 commented May 5, 2019

Yes we got the same behaviour outside the repl.

@smarter
Copy link
Member

smarter commented May 5, 2019

Yeah this is a different issue.

odersky added a commit to dotty-staging/dotty that referenced this issue May 5, 2019
The overloading resolution algorithm dropped alternatives reachable through applys
when testing for applicability. It did so in three situations

 - when comparing the arities of alternatives
 - when testing via isDirectlyApplicable
 - when testing via isApplicable

The third problem stemmed from confusion between overloaded versions
of `isApplicable` (it's ironical that overzealous use of overloading
broke overloading resolution in the compiler!). The version for TermRefs
would not consider `apply` insertion, but the version for Types would.
This means that the overloading broke the Liskov substitution principle. If
a general type happened to be a TermRef the more specific isApplicable
version would kick in, which however did less than the original.
odersky added a commit that referenced this issue May 10, 2019
Fix #6450: Don't drop apply alternatives in overloading resolution
som-snytt added a commit to som-snytt/dotty that referenced this issue Jan 26, 2020
When doing `mkdir -p`, don't fail if an enclosing dir
is an existing symbolic link.

Fix scala#6450
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants