Singleton typed args/results don't interfere with tailcalls #6420
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 withmkAttributedCastHack
inTailcalls
, 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.