-
Notifications
You must be signed in to change notification settings - Fork 21
Sammy gets confused with Java classes #9489
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
Comments
Imported From: https://issues.scala-lang.org/browse/SI-9489?orig=1 |
@lrytz said: |
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Jan 17, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) - 3.0: auto-application takes precedence, but otherwise we always eta-expand warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined`
scala/scala#7660 now eta-expands again in this situation, but we get a warning |
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Jan 17, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) - 3.0: auto-application takes precedence, but otherwise we always eta-expand warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined`
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Jan 17, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) - 3.0: auto-application takes precedence, but otherwise we always eta-expand warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined`
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 4, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) - 3.0: auto-application takes precedence, but otherwise we always eta-expand warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined`
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 5, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined` TODO decide -- currently the condition is more involved to give slack to Scala methods overriding Java-defined ones; I think we should resolve that by introducing slack in overriding e.g. a Java-defined `def toString()` by a Scala-defined `def toString`. This also works better for dealing with accessors overriding Java-defined methods. The current strategy in methodSig is problematic: > // Add a () parameter section if this overrides some method with () parameters > val vparamSymssOrEmptyParamsFromOverride = This means an accessor that overrides a Java-defined method gets a MethodType instead of a `NullaryMethodType`, which breaks lots of assumptions about accessors
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 5, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined` TODO decide -- currently the condition is more involved to give slack to Scala methods overriding Java-defined ones; I think we should resolve that by introducing slack in overriding e.g. a Java-defined `def toString()` by a Scala-defined `def toString`. This also works better for dealing with accessors overriding Java-defined methods. The current strategy in methodSig is problematic: > // Add a () parameter section if this overrides some method with () parameters > val vparamSymssOrEmptyParamsFromOverride = This means an accessor that overrides a Java-defined method gets a MethodType instead of a `NullaryMethodType`, which breaks lots of assumptions about accessors
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 5, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined` TODO decide -- currently the condition is more involved to give slack to Scala methods overriding Java-defined ones; I think we should resolve that by introducing slack in overriding e.g. a Java-defined `def toString()` by a Scala-defined `def toString`. This also works better for dealing with accessors overriding Java-defined methods. The current strategy in methodSig is problematic: > // Add a () parameter section if this overrides some method with () parameters > val vparamSymssOrEmptyParamsFromOverride = This means an accessor that overrides a Java-defined method gets a MethodType instead of a `NullaryMethodType`, which breaks lots of assumptions about accessors
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 5, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined` TODO decide -- currently the condition is more involved to give slack to Scala methods overriding Java-defined ones; I think we should resolve that by introducing slack in overriding e.g. a Java-defined `def toString()` by a Scala-defined `def toString`. This also works better for dealing with accessors overriding Java-defined methods. The current strategy in methodSig is problematic: > // Add a () parameter section if this overrides some method with () parameters > val vparamSymssOrEmptyParamsFromOverride = This means an accessor that overrides a Java-defined method gets a MethodType instead of a `NullaryMethodType`, which breaks lots of assumptions about accessors
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 8, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined` TODO decide -- currently the condition is more involved to give slack to Scala methods overriding Java-defined ones; I think we should resolve that by introducing slack in overriding e.g. a Java-defined `def toString()` by a Scala-defined `def toString`. This also works better for dealing with accessors overriding Java-defined methods. The current strategy in methodSig is problematic: > // Add a () parameter section if this overrides some method with () parameters > val vparamSymssOrEmptyParamsFromOverride = This means an accessor that overrides a Java-defined method gets a MethodType instead of a `NullaryMethodType`, which breaks lots of assumptions about accessors
adriaanm
added a commit
to adriaanm/scala
that referenced
this issue
Feb 10, 2019
Reverse course from the deprecation introduced in 2.12. (4.3) condition for eta-expansion by -Xsource level: - until 2.13: - for arity > 0: function or sam type is expected - for arity == 0: Function0 is expected -- SAM types do not eta-expand because it could be an accidental SAM scala/bug#9489 - 2.14: - for arity > 0: unconditional - for arity == 0: a function-ish type of arity 0 is expected (including SAM) warnings: - 2.12: eta-expansion of zero-arg methods was deprecated (scala/bug#7187) - 2.13: deprecation dropped in favor of setting the scene for uniform eta-expansion in 3.0 warning still available under -Xlint:eta-zero - 2.14: expected type is a SAM that is not annotated with `@FunctionalInterface` if it's a Java-defined interface (under `-Xlint:eta-sam`) (4.2) condition for auto-application by -Xsource level: - until 2.14: none (assuming condition for (4.3) was not met) - in 3.0: `meth.isJavaDefined` TODO decide -- currently the condition is more involved to give slack to Scala methods overriding Java-defined ones; I think we should resolve that by introducing slack in overriding e.g. a Java-defined `def toString()` by a Scala-defined `def toString`. This also works better for dealing with accessors overriding Java-defined methods. The current strategy in methodSig is problematic: > // Add a () parameter section if this overrides some method with () parameters > val vparamSymssOrEmptyParamsFromOverride = This means an accessor that overrides a Java-defined method gets a MethodType instead of a `NullaryMethodType`, which breaks lots of assumptions about accessors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A.java
B.java
Test.scala
Compiling:
The text was updated successfully, but these errors were encountered: