-
Notifications
You must be signed in to change notification settings - Fork 21
-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
Comments
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 |
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`.
I have another point too. Why are all those checks called on the generated code? |
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. |
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. |
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. |
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`.
…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.
…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.
…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.
The following code produces a warning with
-Xsource:2.14
(and-deprecation
) enabled for the following code:The warning is:
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.
The text was updated successfully, but these errors were encountered: