Skip to content

-Xsource:2.14 produces warning for value classes which are wrapping case classes in Scala 2.13.0 #11657

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
crow-fff opened this issue Jul 31, 2019 · 5 comments · Fixed by scala/scala#8296

Comments

@crow-fff
Copy link

The following code produces a warning with -Xsource:2.14 (and -deprecation) enabled for the following code:

case class Bar(x: Int)
class Foo(val bar: Bar) extends AnyVal

The warning is:

Auto-application to () is deprecated. Supply the empty argument list () explicitly to invoke method hashCode, or remove the empty argument list from its definition (Java-defined methods are exempt). In Scala 3, an unapplied method like this will be eta-expanded into a function. class Foo(val bar: Bar) extends AnyVal

Seems like the inspection is called on the compiler generated code for AnyVal (and only when the contained value type is some case class) instead of the original one.

@som-snytt
Copy link

som-snytt commented Jul 31, 2019

This has a direct fix at scala/scala#8010

There is no issue mentioned there, and I don't remember where it came up, probably gitter.

The bit about not exempting java-defined (or overridden) methods is #11639

eed3si9n added a commit to eed3si9n/scala that referenced this issue Aug 1, 2019
Fixes scala/bug#11639
Fixes scala/bug#11657

The compiler gets confused about the lineage of `toString` apparently, so instead of trying to look for the Java flag, I am just going to see if the name exists under `AnyTpe`.
@eed3si9n eed3si9n self-assigned this Aug 1, 2019
@crow-fff
Copy link
Author

crow-fff commented Aug 1, 2019

I have another point too. Why are all those checks called on the generated code?
Is there any way to move them before this phase?
I'm not familiar with the compiler codebase, but if you give me some directions, I can try to figure out how to do it.

@som-snytt
Copy link

The spurious warning was due to normal typechecking of synthetic code that is generated by the compiler. I think it falls under, What's good for the goose is good for the gander. Consider macros, which are typechecked both before and after expansion.

@crow-fff
Copy link
Author

crow-fff commented Aug 1, 2019

What's good for the goose is good for the gander.

The usage of macros is controlled by its user, while a compiler's synthetic code appears out of regular language constructs, and I don't understand why a user should see warnings about this code if there are any.

@eed3si9n
Copy link
Member

eed3si9n commented Aug 1, 2019

I'm on team goose-gander as well.

I think nice that the typechecking or whatever the feature is following the same logic for synthetically generated code. Of course, from the language user's point of view, it's not nice that there's a warning at all, but if there were magical situation where some generated code skipped through the safety rules, I think it would be in a different level of not-niceness when things fail.

We can't always predict these feature interactions, but here we are with two fix PRs.

eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2020
Fixes scala/bug#11639
Fixes scala/bug#11657

The compiler gets confused about the lineage of `toString` apparently, so instead of trying to look for the Java flag, I am just going to see if the name exists under `AnyTpe`.
eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2020
…under -Xsource:2.14

Fixes scala/bug#11639
Fixes scala/bug#11657

The compiler gets confused about the lineage of `toString`.
This follows Dotty's `matchNullaryLoosely` implementation (https://github.com/lampepfl/dotty/blob/811dc19f418f26d6b830bb08bfb49aeee3853a49/compiler/src/dotty/tools/dotc/core/SymDenotations.scala#L950-L957),
which allows `sym.owner == defn.AnyClass` and `sym == defn.Object_clone` in addition to the symbol being Java-defined.
eed3si9n added a commit to eed3si9n/scala that referenced this issue Feb 24, 2020
…under -Xsource:2.14

Fixes scala/bug#11639
Fixes scala/bug#11657

The compiler gets confused about the lineage of `toString`.
This follows Dotty's `matchNullaryLoosely` implementation (https://github.com/lampepfl/dotty/blob/811dc19f418f26d6b830bb08bfb49aeee3853a49/compiler/src/dotty/tools/dotc/core/SymDenotations.scala#L950-L957), which allows `sym.owner == defn.AnyClass` and `sym == defn.Object_clone` in addition to the symbol being Java-defined.
lrytz pushed a commit to eed3si9n/scala that referenced this issue Feb 25, 2020
…under -Xsource:2.14

Fixes scala/bug#11639
Fixes scala/bug#11657

The compiler gets confused about the lineage of `toString`.
This follows Dotty's `matchNullaryLoosely` implementation (https://github.com/lampepfl/dotty/blob/811dc19f418f26d6b830bb08bfb49aeee3853a49/compiler/src/dotty/tools/dotc/core/SymDenotations.scala#L950-L957), which allows `sym.owner == defn.AnyClass` and `sym == defn.Object_clone` in addition to the symbol being Java-defined.
@dwijnand dwijnand added this to the 2.13.2 milestone Mar 16, 2020
julienrf added a commit to endpoints4s/endpoints4s that referenced this issue May 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants