Skip to content

Fix/refs to inner objects #633

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 5 commits into from
Jun 7, 2015

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 7, 2015

Several formerly disabled tests are brought back. One required fixes of references to inner objects. Review by @DarkDimius

odersky added 2 commits June 7, 2015 16:46
A reference to an object from anywhere in its module class can be
established by the This of the module class. The previous behavior always
referenced the object as a term ref which might cause a reference to
the outer This which might not be available (since this is not tracked
by ExplicitOuter). Brings t3174.scala back from disabled.
The tests in this commit pos were verified to work again.
case pre => SelectFromTypeTree(TypeTree(pre), tp)
} // no checks necessary

def ref(sym: Symbol)(implicit ctx: Context): Tree =
ref(NamedType(sym.owner.thisType, sym.name, sym.denot))

private def correctForPath(t: Tree)(implicit ctx: Context) = t match {
Copy link
Contributor

Choose a reason for hiding this comment

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

What does For in the name stand for?
As this method is used only in ref and is private anyway, maybe it's better to move its definition to ref and give it a proper name, eg followOuterLinks?

@DarkDimius
Copy link
Contributor

Otherwise LGTM

odersky added 3 commits June 7, 2015 18:23
Trying to diagnose failure of t2503 and t5577 which were moved
to disabled in the time the tests did not work. These failed
locally for me, but the checkin tests succeeded (since the checkin
tests tested something else).

Added better diagnostics to RefChecks which now mention candidate
implementations of missing abstract members that have the right name but
not the right type.
It's easy to get this wrong. What happened was that when
computing deferred members of a class a deferred member
was preferred over a concrete one because the types did not match.
Thsi should not happen. We now change the scheme to always
prefer concrete over abstract, and subclass-owned over superclass-owned.
But we pick a denotation only if the overrides relationship on types
coincides with the preference on symbols.
@odersky
Copy link
Contributor Author

odersky commented Jun 7, 2015

Since I am in train bringing back disabled tests, here's one more. AFAIK that's all the tests we had to disable in the past weeks, so we should be good on that side for now.

@DarkDimius
Copy link
Contributor

LGTM

DarkDimius added a commit that referenced this pull request Jun 7, 2015
@DarkDimius DarkDimius merged commit 1962ada into scala:master Jun 7, 2015
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