Skip to content

Fix #4753: Direct method should keep Override if overriden nonempty #4792

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
Jul 17, 2018

Conversation

liufengyun
Copy link
Contributor

Fix #4753: Direct method should keep Override if overriden nonempty.

It is the case if the overriden symbol is in the same compilation unit.

…empty

It is the case if the overriden symbol is in the same compilation unit.
@allanrenucci
Copy link
Contributor

allanrenucci commented Jul 13, 2018

It seems to work but there is something fishy. If you compile the classes in the opposite order:

class Foo2 extends Foo1 {
  override def foo: implicit String => Int = 2
}

class Foo1 {
  def foo: implicit String => Int = 1
}

After ShortcutImplicits you get:

class Foo2 extends Foo1 { 
  override def foo: implicit String => Int = {
      def $anonfun(implicit evidence$1: String): Int = 
        this.foo$direct(evidence$1)
      closure($anonfun)
    }
  def foo$direct(implicit x$0: String): Int = 2
}

class Foo1 { 
  def foo: implicit String => Int = {
    def $anonfun(implicit evidence$2: String): Int = 
      this.foo$direct(evidence$2)
    closure($anonfun)
  }
  def foo$direct(implicit x$0: String): Int = 1
}

You can see that foo$direct in Foo2 is missing the override modifier, but RefChecks doesn't complain...

This issue derives from the fact that ShortcutImplicits doesn't have an InfoTransformer. Here @odersky explains why. Maybe the correct fix is to add more special cases to RefChecks.

Alternatively, we could try to move ShortcutImplicits after RefChecks, but we would need to move TailRec as well

@liufengyun
Copy link
Contributor Author

liufengyun commented Jul 13, 2018

Thanks a lot for looking into it @allanrenucci . I think the behavior is expected as when direct method in Foo2 is synthesized and checked in RefChecks, the direct method in Foo1 doesn't exist yet. The fix actually just restores the original logic, it avoids changes to overriding check in RefChecks.

@Blaisorblade
Copy link
Contributor

After discussion in the meeting: If we rely on the Override flag to not mean anything after a certain phase (RefChecks?), which seemed the case, let's please mention this in Override's Scaladocs.

@odersky odersky closed this Jul 16, 2018
@allanrenucci
Copy link
Contributor

@odersky Why was this closed?

@allanrenucci allanrenucci reopened this Jul 17, 2018
Copy link
Contributor

@allanrenucci allanrenucci left a comment

Choose a reason for hiding this comment

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

LGTM. We decided to get this in.

We should document that the Override modifier is meaningless after RefCheck since it is not consistently added by the compiler. This can be done as a separate PR

@allanrenucci allanrenucci merged commit 37a5443 into scala:master Jul 17, 2018
@allanrenucci allanrenucci deleted the fix-4753 branch July 17, 2018 11:33
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.

4 participants