Skip to content
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

Removed overloads are missing, not incompatible #362

Merged
merged 2 commits into from Jul 30, 2019

Conversation

dwijnand
Copy link
Member

@dwijnand dwijnand commented Jul 29, 2019

Previously the method checker didn't take overloading into account, which
means that the loss of a method overload (which includes the loss of a
static forwarder method overload, such as when upgrading from Scala 2.12.7 to 2.12.8+) was
reported as an "incompatible method type" problem or a
"incompatible result type" problem.

With this change these are now correctly reported as "direct missing
method" problems.

Previously the method checker didn't take overloading into account,
which means that the loss of a method overloading (which includes the
loss of a static forwarder methods, when upgrading from Scala 2.12.7 to
2.12.8+) was reported as an "incompatible method type" problem or a
"incompatible result type" problem.

With this change these are now correctly reported as "direct missing
method" problems.
@dwijnand dwijnand requested a review from lrytz July 29, 2019 16:56
@dwijnand dwijnand added this to the 0.6.0 milestone Jul 29, 2019
@dwijnand
Copy link
Member Author

This is in relation to #361, where it was discovered that the change in 2.12.8 that dropped the method overload for static forwarders for bridge methods (for example static Symbol.apply(Object)Object, bridge for the Function1 that Symbol inherits) were showing up as "incompatible type" problems, instead of just dropped methods.

Copy link
Contributor

@lrytz lrytz left a comment

Choose a reason for hiding this comment

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

👍 Looks good!

else
super.check(method, inclazz.lookupClassMethods(method.bytecodeName))
super.check(method, inclazz, _.lookupClassMethods(method.bytecodeName))
Copy link
Contributor

Choose a reason for hiding this comment

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

The lookup function is used for old and new, I wonder if there is a case when we get a misleading error message if a method is removed and only exists in a parent trait in the new version.

Generally, maybe can you explain why a different lookup function is used if meth.isDeferred?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, I can't. It's a part of the code that I don't understand and just try to preserve the existing semantics.

Copy link
Contributor

Choose a reason for hiding this comment

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

👍 for your pragmatism

@dwijnand dwijnand merged commit fcf7d64 into lightbend:master Jul 30, 2019
@dwijnand dwijnand deleted the removed-overloads branch July 30, 2019 08:10
dwijnand added a commit to dwijnand/mima that referenced this pull request Oct 5, 2019
In lightbend#362 I changed the logic so that when an overloaded is dropped it
doesn't get reported as an "incompatible method type" or "incompatible
result type" problem.

Looking back the logic is quite short-sighted.

So here I attempt to make it more straight-forward: if there were
overloads, then the method is missing - it's not incompatible.
dwijnand added a commit to dwijnand/mima that referenced this pull request Oct 5, 2019
In lightbend#362 I changed the logic so that when an overloaded is dropped it
doesn't get reported as an "incompatible method type" or "incompatible
result type" problem.

Looking back the logic is quite short-sighted.

So here I attempt to make it more straight-forward: if there were
overloads, then the method is missing - it's not incompatible.
dwijnand added a commit to dwijnand/mima that referenced this pull request Oct 5, 2019
In lightbend#362 I changed the logic so that when an overloaded is dropped it
doesn't get reported as an "incompatible method type" or "incompatible
result type" problem.

Looking back the logic is quite short-sighted.

So here I attempt to make it more straight-forward: if there were
overloads, then the method is missing - it's not incompatible.
dwijnand added a commit to dwijnand/mima that referenced this pull request Oct 5, 2019
In lightbend#362 I changed the logic so that when an overloaded is dropped it
doesn't get reported as an "incompatible method type" or "incompatible
result type" problem.

Looking back the logic is quite short-sighted.

So here I attempt to make it more straight-forward: if there were
overloads, then the method is missing - it's not incompatible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants