-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New bridge implementation #2342
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
Conversation
@odersky, the first patch apparently doesn't break anything in our test-suite. |
It turns out that bridges are severely undertested. In fact, we have an extensive test for bridges but it never made it out of pending. If I run the current implementation on this one I get:
|
Rebased over #2331. I verified that with these changes (and the custom Either) the collection strawman now compiles and tests OK. |
Those forwarders may disrupt method resolution.
This one is based on the way things are done in scalac. As yet missing: Systematic treatment of errors. Test i1240a was moved to pending. It caused a merge error before but this was likely accidental. We have to check whether systematic bridge error checking will discover a problem. For the moment the test behaves exactly as for scalac: it compiles and the result is the same.
Was info before, but signatures already contain all the information we need and are cheaper to test for equality.
Note: error diagnostic is still missing. |
We were missing "has same signature after erasure" errors if the two methods in questions came from different parents.
@@ -11,6 +11,9 @@ import TypeErasure.ErasedValueType, ValueClasses._ | |||
/** This phase erases ErasedValueType to their underlying type. | |||
* It also removes the synthetic cast methods u2evt$ and evt2u$ which are | |||
* no longer needed afterwards. | |||
* Finally, it checks that we don't introduce "double definitions" of pairs |
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.
Why put this in ElimErasedValueType
? Shouldn't it be a separate mini-phase?
I knew you would say this 😀. There's some logic to put it here because at the end of ElimErasedValueTypes all denotations have the types that we need to check the condition. Creating lots of new phases has a cognitive cost as well. |
I'll leave my vote for making a |
No description provided.