Fix #8736: Handle alternatives with same signature in overloading resolution #8822
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It always goes to `err`, so no need to abstract over it.
Turn an assertion into an checked error with an error message pointing to the root of the problem.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Turn an assertion into an checked error with an error message
pointing to the root of the problem.
It would be nice if we managed to compile #8736, but this looks out of reach for the time being. The problem is that we generate overloaded denotations where alternatives have the same TermRef, since the different denotations have different types (method types over singleton types), yet their signature is the same since all these method types erase to the same one.
if the program was written with regular methods this would give an error saying that the different versions have the same signature after erasure. #8736 tries to cleverly get around that restriction by using structural types. But that will not work either, I am afraid. Making it work by tweaking the compiler would be extremely hard since basically all our low level infrastructure is built around signatures and erasure. This is in order to get acceptable performance in the presence of intersection types. I have no idea whether one could redesign the compiler infrastructure dropping signatures and still get acceptable performance. I doubt it, though, and won't try to do that.