Skip to content

type inference does not respect access boundaries #4114

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
scabug opened this issue Dec 26, 2010 · 4 comments
Closed

type inference does not respect access boundaries #4114

scabug opened this issue Dec 26, 2010 · 4 comments
Assignees

Comments

@scabug
Copy link

scabug commented Dec 26, 2010

abstract class A {
  private def foo = List(1, 2)
}
trait B extends A {
  private def foo = List("a", "b")
  // However it compiles correctly if the type is given:
  // private def foo: List[String] = List("a", "b")
}
% scalac29 -version
Scala compiler version 2.9.0.r23832-b20101223012507 -- Copyright 2002-2010, LAMP/EPFL
% scalac29 bug.scala
bug.scala:5: error: type mismatch;
 found   : java.lang.String("a")
 required: Int
  private def foo = List("a", "b")
                         ^
bug.scala:5: error: type mismatch;
 found   : java.lang.String("b")
 required: Int
  private def foo = List("a", "b")
                              ^
two errors found
@scabug
Copy link
Author

scabug commented Dec 26, 2010

Imported From: https://issues.scala-lang.org/browse/SI-4114?orig=1
Reporter: @paulp

@scabug
Copy link
Author

scabug commented Jan 8, 2011

@paulp said:
I've just noticed #2441 is a duplicate of this, so I'm closing that and keeping this one - but that one is worth checking out as well. The situation there looks to be specific to companions, and is along the lines of:

class T
trait A { def f: T }
object Bob {
  private class X extends T
}
class Bob extends A {
  def f = new Bob.X
}  

That should either fail to compile, or the type inferred for f in Bob should be T. Instead it is Bob.X.

@scabug
Copy link
Author

scabug commented Jan 9, 2011

@odersky said:
(In r23935) Closes #4114. No review.

@scabug
Copy link
Author

scabug commented Jan 10, 2011

@paulp said:
(In r23958) A test case for recently fixed #4114. Plus!

I had closed #2441 as a duplicate of that, but unfortunately #4114 did
not bring #2441 along with it. Then I realized I'm a programmer, not a
helpless trac watcher. As is often the case with thes things, fixing that
revealed a bug in the library. Closes #2441 for real, review by odersky.

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

No branches or pull requests

2 participants