Skip to content

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

Closed
scabug opened this issue Sep 25, 2015 · 4 comments
Closed

Sammy gets confused with Java classes #9489

scabug opened this issue Sep 25, 2015 · 4 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Sep 25, 2015

A.java

public class A {
  public B b() { return null; }
}

B.java

public abstract class B {
  public abstract int m();
}

Test.scala

class T {
  def f(a: A) = g(a.b)
  def g(b: => B) = null
}

Compiling:

$ javac A.java B.java
$ scalac -Xexperimental A.scala -Xprint:typer
A.scala:2: error: type mismatch;
 found   : B
 required: Int
  def f(a: A) = g(a.b)
                    ^
[[syntax trees at end of                     typer]] // A.scala
package <empty> {
  class T extends scala.AnyRef {
    def <init>(): T = {
      T.super.<init>();
      ()
    };
    def <f: error>(a: A): <error> = T.this.g(a.b);
    def g(b: => B): Null = null
  }
}

one error found
@scabug
Copy link
Author

scabug commented Sep 25, 2015

Imported From: https://issues.scala-lang.org/browse/SI-9489?orig=1
Reporter: @lrytz
Affected Versions: 2.11.7
See #9178

@scabug
Copy link
Author

scabug commented Sep 25, 2015

@lrytz said:
This was found while trying to bootstrap with sammy enabled, see scala/scala#4767

@scabug
Copy link
Author

scabug commented Oct 27, 2015

@retronym said:
Duplicate of #9178

@scabug scabug closed this as completed Oct 27, 2015
@scabug scabug added this to the 2.12.0-M4 milestone Apr 7, 2017
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
Copy link
Contributor

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
Projects
None yet
Development

No branches or pull requests

3 participants