-
Notifications
You must be signed in to change notification settings - Fork 71
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
False negatives for methods moving up in trait hierarchy #426
Comments
Thanks for the detailed issue. If you want to share the patch we can have a look together. |
Btw, I thought this sounded like #237, but re-reading that one's different. |
@dwijnand Right, if these were classes I don't think this specific synthetic static method issue would be a problem. Here's the change I was using to find these in Cats: https://github.com/travisbrown/mima/tree/topic/cats-3162-check Thanks for taking a look! |
Took a mini step forward today and ran that patch against the test suite and it broke the following tests:
https://travis-ci.com/dwijnand/mima/jobs/259571256 I might come back to this, this weekend. |
@dwijnand Thanks for looking! The problem is that at least some of the tests are wrong—e.g. |
Ah, yes, you'd already mentioned that. I'll try to study this tomorrow and push a patch for review. |
MiMa filters out most synthetic methods under the assumption that any compatibility error in those would also be caught in a non-synthetic method (and the latter one is the error that users should see). This clearly doesn't work for static trait implementation methods. I'm surprised that we didn't encounter this bug much sooner. |
On second thought, perhaps it is not that surprising after all. Our own use of MiMa for the Scala standard library would not be affected because such a change is not forward binary compatible anyway. |
In the encoding of traits the presence of a method with a body (a "concrete method") triggers the generation of a trait initialisation method, "$init$", which will be invoked by subclasses during construction. The effect this has is that dropping the last concrete method(s) from a trait _removes_ the trait init method, which is a binary incompatible change to client's subclasses. Fixes lightbend-labs#426
In the encoding of traits the presence of a method with a body (a "concrete method") triggers the generation of a trait initialisation method, "$init$", which will be invoked by subclasses during construction. The effect this has is that dropping the last concrete method(s) from a trait _removes_ the trait init method, which is a binary incompatible change to client's subclasses. Fixes lightbend-labs#426
In the encoding of traits the presence of a method with a body (a "concrete method") triggers the generation of a trait initialisation method, "$init$", which will be invoked by subclasses during construction. The effect this has is that dropping the last concrete method(s) from a trait _removes_ the trait init method, which is a binary incompatible change to client's subclasses. Fixes lightbend-labs#426
In the encoding of traits the presence of a method with a body (a "concrete method") triggers the generation of a trait initialisation method, "$init$", which will be invoked by subclasses during construction. The effect this has is that dropping the last concrete method(s) from a trait _removes_ the trait init method, which is a binary incompatible change to client's subclasses. Fixes lightbend-labs#426
In the encoding of traits the presence of a method with a body (a "concrete method") triggers the generation of a trait initialisation method, "$init$", which will be invoked by subclasses during construction. The effect this has is that dropping the last concrete method(s) from a trait _removes_ the trait init method, which is a binary incompatible change to client's subclasses. Fixes lightbend-labs#426
This bug just hit us in the Cats 2.1.0-RC1 release, where we moved an instance method from the
MonadError
type class trait to itsApplicativeError
supertype, which MiMa said was fine, but which actually breaks binary compatibility on both 2.12 and 2.13: typelevel/cats#3162The problem is the synthetic
myMethod$
static implementation method, which no longer exists on the trait that themyMethod
instance method was moved out of. Adding an override in this trait fixes the bincompat issue, but that doesn't work if for example the method was implicit and was moved in order to adjust prioritization.It seems like this should be a pretty straightforward
DirectMissingMethodProblem
, and there's already atrait-pushing-up-concrete-methods-is-nok
test that covers exactly this case—the problem is that the test states that there shouldn't be problems on 2.12+, when it definitely should be identifying problems.I have a MiMa branch with a fix that does what I need to check this Cats release (it's a two-line change—I'm just filtering static methods out of the interface method lookup and not treating these synthetic methods as inaccessible), but someone who's more familiar with the MiMa implementation could probably do this in a more principled way.
The text was updated successfully, but these errors were encountered: