Skip to content

Fix of #39 #42

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

Merged
merged 1 commit into from
Mar 6, 2014
Merged

Fix of #39 #42

merged 1 commit into from
Mar 6, 2014

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Mar 4, 2014

Two fixes:

  1. Avoid the infinite recursion in checkAccessible if the accessibility check fails.
  2. Make accessibility succeed for the test, and in general if the target denotation does not have a symbol.

Added original test in pos and a negative test which makes accessibility fail.

Review by @DarkDimius, @samuelgruetter

Two fixes:
1) Avoid the infinite recursion in checkAccessible if the accessibility check fails.
2) Make accessibility succeed for the test, and in general if the target denotation does not have a symbol.

Added original test in pos and a negative test which makes accessibility fail.
@@ -40,6 +40,7 @@ class tests extends CompilerTest {
@Test def pos_overloaded() = compileFile(posDir, "overloaded")
@Test def pos_templateParents() = compileFile(posDir, "templateParents")
@Test def pos_structural() = compileFile(posDir, "structural")
@Test def pos_i39 = compileFile(posDir, "i39")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have a http link for this issue on github, as "i39" is not so obvious.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think should have a naming convention for issue tests, then it will become obvious. Scala 2 has t123, should we do the same or stick with i123?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having such convention seems good idea.
I'd prefer i123.

@DarkDimius
Copy link
Contributor

Otherwise Ok for me

@DarkDimius
Copy link
Contributor

LGTM

@samuelgruetter
Copy link
Contributor

Not sure if this is an issue: In

object test241 {

  trait A {
    def foo(i: Int): String = ???
    def foo(s: String): String = ???
  }

  class B extends A {
    private def foo(s: String): String = ???
  }

  println((new B).foo(""))

}

I get

error: type mismatch:
found   : String("")
required: Int
println((new B).foo(""))
                    ^

so the foo(String) of super cannot be accessed. But if I remove the foo(Int), the foo(String) of super can be accessed. This is inconsistant. But, on the other hand, Scala 2.10.3 behaves the same.

val where = if (ctx.owner.exists) s" from ${ctx.owner.enclosingClass}" else ""
val whyNot = new StringBuffer
val addendum =
alts foreach (_.isAccessibleFrom(pre, superAccess, whyNot))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do you assign Unit to a val?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I will do a shortcut in the interest of time and fix it in the next commit.

odersky added a commit that referenced this pull request Mar 6, 2014
@odersky odersky merged commit 6ada020 into scala:master Mar 6, 2014
WojciechMazur pushed a commit to WojciechMazur/dotty that referenced this pull request Mar 19, 2025
Backport "Fix tupleTypeFromSeq for XXL tuples" to 3.3 LTS
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

Successfully merging this pull request may close these issues.

3 participants