Skip to content

Singleton typed args/results don't interfere with tailcalls #6420

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 2 commits into from
Apr 11, 2018

Conversation

milessabin
Copy link
Contributor

At one point the literal types PR modified the semantics of asInstanceOf to check for equality of the target value with the value embedded in the singleton type. This interacted badly with mkAttributedCastHack in Tailcalls, because the inserted casts could end up referring to a non-existent symbol which would be needed to implement the equality check during erasure.

The fix at the time was to make the use of a singleton type as a method argument or result type disqualify the method from having the tailcall optimization applied. A later decision by the SIP committee decided for unrelated reasons that an asInstanceOf test should not perform an equality check, so this disqualification became unnecessary. It was not removed, however.

This came to light because singleton types are used as method argument and result types in methods which are expected to have the tail call optimization applied, resulting in scala/scala-dev#467. We fix that here by doing what should have been done earlier: removing the disqualification.

Fixes scala/scala-dev#467.

At one point the literal types PR modified the semantics of asInstanceOf
to check for equality of the target value with the value embedded in the
singleton type. This interacted badly with mkAttributedCastHack in
Tailcalls,

  dotta@c2534bf

because the inserted casts could end up referring to a non-existent
Symbol which would be needed to implement the equality check during
Erasure.

The fix at the time was to make the use of a singleton type as a method
argument or result type disqualify the method from having the tailcall
optimization applied. A later decision by the SIP committee decided for
unrelated reasons that an asInstanceOf test should not perform an
equality check, so this disqualification became unnecessary. It was not
removed, however.

This came to light because singleton types are used as method argument
and result types in methods which are expected to have the tail call
optimizatino applied, resulting in,

  scala/scala-dev#467

We fix that here by doing what should have been done earlier: removing
the disqualification.
Copy link
Member

@retronym retronym left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for explaining the backstory.

@adriaanm adriaanm merged commit 77db1d2 into scala:2.13.x Apr 11, 2018
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.

2.13 regression in @tailrec + singleton types
3 participants