From 8149cc8575c342304040a41502ef3463938ea92a Mon Sep 17 00:00:00 2001 From: Arnout Engelen Date: Thu, 5 Dec 2019 13:26:24 +0100 Subject: [PATCH 1/5] Clarify IncompatibleSignatureProblem message --- core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala b/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala index 76cc1801..e0f575bf 100644 --- a/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala +++ b/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala @@ -41,7 +41,7 @@ sealed abstract class Problem extends ProblemRef { case ReversedMissingMethodProblem(ref) => s"${ref.memberString} is present only in $affectedVersion version" case FinalMethodProblem(ref) => s"${ref.methodString} is declared final in $affectedVersion version" case IncompatibleResultTypeProblem(ref, newmeth) => s"${ref.methodString} has a different result type in $affectedVersion version, where it is ${newmeth.tpe.resultType} rather than ${ref.tpe.resultType}" - case IncompatibleSignatureProblem(ref, newmeth) => s"${ref.methodString} has a different signature in $affectedVersion version, where it is ${orMIA(newmeth.signature)} rather than ${orMIA(ref.signature)}" + case IncompatibleSignatureProblem(ref, newmeth) => s"${ref.methodString} has a different signature in $affectedVersion version, where it is ${orMIA(newmeth.signature)} rather than ${orMIA(ref.signature)}. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out" case DirectAbstractMethodProblem(ref) => s"${ref.methodString} does not have a correspondent in $affectedVersion version" case ReversedAbstractMethodProblem(ref) => s"in $affectedVersion version there is ${ref.methodString}, which does not have a correspondent" case UpdateForwarderBodyProblem(ref) => s"in $affectedVersion version, classes mixing ${ref.owner.fullName} needs to update body of ${ref.shortMethodString}" From 815a3b7c9a0b34eab53e74d407b3566836dbd7d0 Mon Sep 17 00:00:00 2001 From: Arnout Engelen Date: Thu, 5 Dec 2019 14:28:51 +0100 Subject: [PATCH 2/5] Fix functional test expectations --- .../problems.txt | 6 +++--- .../class-method-generics-nok/problems.txt | 20 +++++++++---------- .../problems.txt | 2 +- 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/functional-tests/src/test/class-constructor-generics-nok/problems.txt b/functional-tests/src/test/class-constructor-generics-nok/problems.txt index 5924b197..6d1f2212 100644 --- a/functional-tests/src/test/class-constructor-generics-nok/problems.txt +++ b/functional-tests/src/test/class-constructor-generics-nok/problems.txt @@ -1,3 +1,3 @@ -method source()scala.Tuple2 in class OptionPane has a different signature in new version, where it is ()Lscala/Tuple2;Ljava/lang/String;>; rather than ()Lscala/Tuple2; -method show()java.lang.Object in class OptionPane has a different signature in new version, where it is ()TA; rather than -method this(scala.Tuple2)Unit in class OptionPane has a different signature in new version, where it is (Lscala/Tuple2;Ljava/lang/String;>;)V rather than (Lscala/Tuple2;)V +method source()scala.Tuple2 in class OptionPane has a different signature in new version, where it is ()Lscala/Tuple2;Ljava/lang/String;>; rather than ()Lscala/Tuple2;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method show()java.lang.Object in class OptionPane has a different signature in new version, where it is ()TA; rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method this(scala.Tuple2)Unit in class OptionPane has a different signature in new version, where it is (Lscala/Tuple2;Ljava/lang/String;>;)V rather than (Lscala/Tuple2;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out diff --git a/functional-tests/src/test/class-method-generics-nok/problems.txt b/functional-tests/src/test/class-method-generics-nok/problems.txt index 6cdd1a85..5fa44f9d 100644 --- a/functional-tests/src/test/class-method-generics-nok/problems.txt +++ b/functional-tests/src/test/class-method-generics-nok/problems.txt @@ -1,12 +1,12 @@ -method genericWithChangingName()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option; -method backwardsCompatibleNarrowing()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option; +method genericWithChangingName()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method backwardsCompatibleNarrowing()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out # -method cov1()java.lang.Object in class Api has a different signature in new version, where it is ()TA; rather than -method cov2()java.lang.Object in class Api has a different signature in new version, where it is rather than ()TT; -method con1(java.lang.Object)Unit in class Api has a different signature in new version, where it is (TA;)V rather than -method con2(java.lang.Object)Unit in class Api has a different signature in new version, where it is rather than (TT;)V +method cov1()java.lang.Object in class Api has a different signature in new version, where it is ()TA; rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method cov2()java.lang.Object in class Api has a different signature in new version, where it is rather than ()TT;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method con1(java.lang.Object)Unit in class Api has a different signature in new version, where it is (TA;)V rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method con2(java.lang.Object)Unit in class Api has a different signature in new version, where it is rather than (TT;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out # -abstract method cov1()java.lang.Object in class Abi has a different signature in new version, where it is ()TA; rather than -abstract method cov2()java.lang.Object in class Abi has a different signature in new version, where it is rather than ()TT; -abstract method con1(java.lang.Object)Unit in class Abi has a different signature in new version, where it is (TA;)V rather than -abstract method con2(java.lang.Object)Unit in class Abi has a different signature in new version, where it is rather than (TT;)V +abstract method cov1()java.lang.Object in class Abi has a different signature in new version, where it is ()TA; rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +abstract method cov2()java.lang.Object in class Abi has a different signature in new version, where it is rather than ()TT;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +abstract method con1(java.lang.Object)Unit in class Abi has a different signature in new version, where it is (TA;)V rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +abstract method con2(java.lang.Object)Unit in class Abi has a different signature in new version, where it is rather than (TT;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out diff --git a/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt b/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt index 7f0da347..ffe91b3b 100644 --- a/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt +++ b/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt @@ -1 +1 @@ -method foo()scala.Tuple2 in class A has a different signature in new version, where it is ()Lscala/Tuple2; rather than ()Lscala/Tuple2; \ No newline at end of file +method foo()scala.Tuple2 in class A has a different signature in new version, where it is ()Lscala/Tuple2; rather than ()Lscala/Tuple2;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out From bbe0add5b01e47642c3194cbf2a3a73b608e007a Mon Sep 17 00:00:00 2001 From: Arnout Engelen Date: Thu, 5 Dec 2019 14:49:04 +0100 Subject: [PATCH 3/5] One more --- .../src/test/value-class-generic-replacement-nok/problems.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt b/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt index c1bb83a7..22a7af40 100644 --- a/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt +++ b/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt @@ -1 +1 @@ -method boxedStringy()scala.Option in class Bar has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option; +method boxedStringy()scala.Option in class Bar has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out From 45730b938861676e0546108d479c2aed28f061d1 Mon Sep 17 00:00:00 2001 From: Dale Wijnand <344610+dwijnand@users.noreply.github.com> Date: Thu, 5 Dec 2019 14:22:17 +0000 Subject: [PATCH 4/5] Link IncompatibleSignatureProblem to the README Co-Authored-By: Arnout Engelen --- core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala b/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala index e0f575bf..e4195805 100644 --- a/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala +++ b/core/src/main/scala/com/typesafe/tools/mima/core/Problems.scala @@ -41,7 +41,7 @@ sealed abstract class Problem extends ProblemRef { case ReversedMissingMethodProblem(ref) => s"${ref.memberString} is present only in $affectedVersion version" case FinalMethodProblem(ref) => s"${ref.methodString} is declared final in $affectedVersion version" case IncompatibleResultTypeProblem(ref, newmeth) => s"${ref.methodString} has a different result type in $affectedVersion version, where it is ${newmeth.tpe.resultType} rather than ${ref.tpe.resultType}" - case IncompatibleSignatureProblem(ref, newmeth) => s"${ref.methodString} has a different signature in $affectedVersion version, where it is ${orMIA(newmeth.signature)} rather than ${orMIA(ref.signature)}. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out" + case IncompatibleSignatureProblem(ref, newmeth) => s"${ref.methodString} has a different generic signature in $affectedVersion version, where it is ${orMIA(newmeth.signature)} rather than ${orMIA(ref.signature)}. See https://github.com/lightbend/mima#incompatiblesignatureproblem" case DirectAbstractMethodProblem(ref) => s"${ref.methodString} does not have a correspondent in $affectedVersion version" case ReversedAbstractMethodProblem(ref) => s"in $affectedVersion version there is ${ref.methodString}, which does not have a correspondent" case UpdateForwarderBodyProblem(ref) => s"in $affectedVersion version, classes mixing ${ref.owner.fullName} needs to update body of ${ref.shortMethodString}" From 029821377bdc96da58f5e548d2b5cc50cf643760 Mon Sep 17 00:00:00 2001 From: Arnout Engelen Date: Thu, 5 Dec 2019 15:36:52 +0100 Subject: [PATCH 5/5] Fix expectations again :D --- .../problems.txt | 6 +++--- .../class-method-generics-nok/problems.txt | 20 +++++++++---------- .../problems.txt | 2 +- .../problems.txt | 2 +- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/functional-tests/src/test/class-constructor-generics-nok/problems.txt b/functional-tests/src/test/class-constructor-generics-nok/problems.txt index 6d1f2212..f5f5fb83 100644 --- a/functional-tests/src/test/class-constructor-generics-nok/problems.txt +++ b/functional-tests/src/test/class-constructor-generics-nok/problems.txt @@ -1,3 +1,3 @@ -method source()scala.Tuple2 in class OptionPane has a different signature in new version, where it is ()Lscala/Tuple2;Ljava/lang/String;>; rather than ()Lscala/Tuple2;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -method show()java.lang.Object in class OptionPane has a different signature in new version, where it is ()TA; rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -method this(scala.Tuple2)Unit in class OptionPane has a different signature in new version, where it is (Lscala/Tuple2;Ljava/lang/String;>;)V rather than (Lscala/Tuple2;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method source()scala.Tuple2 in class OptionPane has a different generic signature in new version, where it is ()Lscala/Tuple2;Ljava/lang/String;>; rather than ()Lscala/Tuple2;. See https://github.com/lightbend/mima#incompatiblesignatureproblem +method show()java.lang.Object in class OptionPane has a different generic signature in new version, where it is ()TA; rather than . See https://github.com/lightbend/mima#incompatiblesignatureproblem +method this(scala.Tuple2)Unit in class OptionPane has a different generic signature in new version, where it is (Lscala/Tuple2;Ljava/lang/String;>;)V rather than (Lscala/Tuple2;)V. See https://github.com/lightbend/mima#incompatiblesignatureproblem diff --git a/functional-tests/src/test/class-method-generics-nok/problems.txt b/functional-tests/src/test/class-method-generics-nok/problems.txt index 5fa44f9d..2c9b1ca7 100644 --- a/functional-tests/src/test/class-method-generics-nok/problems.txt +++ b/functional-tests/src/test/class-method-generics-nok/problems.txt @@ -1,12 +1,12 @@ -method genericWithChangingName()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -method backwardsCompatibleNarrowing()scala.Option in class A has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method genericWithChangingName()scala.Option in class A has a different generic signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. See https://github.com/lightbend/mima#incompatiblesignatureproblem +method backwardsCompatibleNarrowing()scala.Option in class A has a different generic signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. See https://github.com/lightbend/mima#incompatiblesignatureproblem # -method cov1()java.lang.Object in class Api has a different signature in new version, where it is ()TA; rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -method cov2()java.lang.Object in class Api has a different signature in new version, where it is rather than ()TT;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -method con1(java.lang.Object)Unit in class Api has a different signature in new version, where it is (TA;)V rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -method con2(java.lang.Object)Unit in class Api has a different signature in new version, where it is rather than (TT;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method cov1()java.lang.Object in class Api has a different generic signature in new version, where it is ()TA; rather than . See https://github.com/lightbend/mima#incompatiblesignatureproblem +method cov2()java.lang.Object in class Api has a different generic signature in new version, where it is rather than ()TT;. See https://github.com/lightbend/mima#incompatiblesignatureproblem +method con1(java.lang.Object)Unit in class Api has a different generic signature in new version, where it is (TA;)V rather than . See https://github.com/lightbend/mima#incompatiblesignatureproblem +method con2(java.lang.Object)Unit in class Api has a different generic signature in new version, where it is rather than (TT;)V. See https://github.com/lightbend/mima#incompatiblesignatureproblem # -abstract method cov1()java.lang.Object in class Abi has a different signature in new version, where it is ()TA; rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -abstract method cov2()java.lang.Object in class Abi has a different signature in new version, where it is rather than ()TT;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -abstract method con1(java.lang.Object)Unit in class Abi has a different signature in new version, where it is (TA;)V rather than . Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out -abstract method con2(java.lang.Object)Unit in class Abi has a different signature in new version, where it is rather than (TT;)V. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +abstract method cov1()java.lang.Object in class Abi has a different generic signature in new version, where it is ()TA; rather than . See https://github.com/lightbend/mima#incompatiblesignatureproblem +abstract method cov2()java.lang.Object in class Abi has a different generic signature in new version, where it is rather than ()TT;. See https://github.com/lightbend/mima#incompatiblesignatureproblem +abstract method con1(java.lang.Object)Unit in class Abi has a different generic signature in new version, where it is (TA;)V rather than . See https://github.com/lightbend/mima#incompatiblesignatureproblem +abstract method con2(java.lang.Object)Unit in class Abi has a different generic signature in new version, where it is rather than (TT;)V. See https://github.com/lightbend/mima#incompatiblesignatureproblem diff --git a/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt b/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt index ffe91b3b..3ff3fb18 100644 --- a/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt +++ b/functional-tests/src/test/tuple-parametric-type-change-nok/problems.txt @@ -1 +1 @@ -method foo()scala.Tuple2 in class A has a different signature in new version, where it is ()Lscala/Tuple2; rather than ()Lscala/Tuple2;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method foo()scala.Tuple2 in class A has a different generic signature in new version, where it is ()Lscala/Tuple2; rather than ()Lscala/Tuple2;. See https://github.com/lightbend/mima#incompatiblesignatureproblem diff --git a/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt b/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt index 22a7af40..5f0e427b 100644 --- a/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt +++ b/functional-tests/src/test/value-class-generic-replacement-nok/problems.txt @@ -1 +1 @@ -method boxedStringy()scala.Option in class Bar has a different signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. Note that the erased signature is still consistent. This means this change in the generics may or may not lead to problems at runtime, and possibly can be safely filtered out +method boxedStringy()scala.Option in class Bar has a different generic signature in new version, where it is ()Lscala/Option; rather than ()Lscala/Option;. See https://github.com/lightbend/mima#incompatiblesignatureproblem