-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix/refs to inner objects #633
Conversation
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 { |
There was a problem hiding this comment.
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
?
Otherwise LGTM |
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.
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. |
LGTM |
Several formerly disabled tests are brought back. One required fixes of references to inner objects. Review by @DarkDimius