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

private method shadows directly inherited public method #8143

Closed
scabug opened this issue Jan 12, 2014 · 6 comments
Closed

private method shadows directly inherited public method #8143

scabug opened this issue Jan 12, 2014 · 6 comments

Comments

@scabug
Copy link

@scabug scabug commented Jan 12, 2014

This does not compile in 2.10, but does in master.

class Foo { def f = 5 }
class Bar extends Foo { private def f = 10 }

I think it regressed in e609f1f20b . The test case run/private-override.scala looks wrong - class Other is supposed to be in some package other than p2 to test what it is intending to test. I believe that bug is legit, just the test case is wrong, but also that it is the change which accompanied it which caused the bug being reported here.

@scabug
Copy link
Author

@scabug scabug commented Jan 12, 2014

@scabug
Copy link
Author

@scabug scabug commented Jan 12, 2014

@retronym said (edited on Jan 12, 2014 12:16:32 PM UTC):
For reference, the Java behaviour is like ours in 2.10:

tail sandbox/{Test,Sub}.java
==> sandbox/Test.java <==
class Test {
	public int foo() { return 0; }
}

==> sandbox/Sub.java <==
class Sub extends Test {
	private int foo() { return 0; }
}
  /code/scala javac sandbox/{Test,Sub}.java
sandbox/Sub.java:2: foo() in Sub cannot override foo() in Test; attempting to assign weaker access privileges; was public
	private int foo() { return 0; }
	            ^
1 error

@scabug
Copy link
Author

@scabug scabug commented Jan 12, 2014

@paulp said:
Note that slight variations are allowed even in 2.10 and prior.

class A { def f = 5 }
class B extends A { private[B] def f = 10 }

Not sure how that can be acceptable if straight private isn't.

@scabug
Copy link
Author

@scabug scabug commented Jan 12, 2014

@retronym said:
Good catch.

Seems like every call to Symbol#isPrivate represents a potential bug:

scala> object O { trait T { private[O] def foo = 0 } }
defined module O

scala> val foo = typeOf[O.T].member(newTermName("foo"))
foo: $r.intp.global.Symbol = method foo

scala> foo.isPrivate
res0: Boolean = false

scala> foo.privateWithin
res1: $r.intp.global.Symbol = object O
// RefChecks
if (member.isPrivate) // (1.1)
            overrideError("has weaker access privileges; it should not be private")
          member.privateWithin

@scabug
Copy link
Author

@scabug scabug commented Jan 12, 2014

@retronym said:
Fixing the regression: scala/scala#3357

@scabug
Copy link
Author

@scabug scabug commented Jan 16, 2014

@retronym said:
Followup to track the issues with qualified private.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants