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

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

Open
crow-fff opened this issue Jul 31, 2019 · 5 comments

Comments

@crow-fff
Copy link

commented Jul 31, 2019

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

This comment has been minimized.

Copy link

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 x.toString causing auto-application warnings under -Xsource:2.14
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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link

commented Aug 1, 2019

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.