Avoid brittle flags encoding for Java enums#10424
Conversation
3a608df to
88d252f
Compare
88d252f to
51ce3e8
Compare
Is that kludge something we've had since forever, or something that was added recently? I guess I'm asking partly out of curiosity and partly because I'm wondering what the risk level is of making a code improvement that isn't strictly necessary to fix bug (right?). In other words, my "shouldn't this be two PRs" finger is twitching slightly, but my "Seth don't be pedantic" finger is twitching in the direction of the first finger, if the metaphor isn't getting too tortured. |
|
To overthink a little further, I guess whether I care about one-PR-or-two depends on whether 2.13.12 ends up being a longer-incubating, optimistically-merge-things type release (as 2.13.11 was), or whether it ends up being an "oh shit we need to roll another one pronto" type release (as 2.13.10 was). And we don't know that yet. |
|
@SethTisue I expect @lrytz to weigh in on the second commit, hopefully with a ringing endorsement. Otherwise it can be moved to a separate PR as an internal improvement. (It's an old state of affairs, but I think it turns out to be low-hanging fruit. If I'd been at the recent spree, I would have worn my "low-hanging fruit" t-shirt.) |
lrytz
left a comment
There was a problem hiding this comment.
LGTM, both commits, just the isSealedEnum extension method seems a bit of an overkill.
src/compiler/scala/tools/nsc/backend/jvm/BTypesFromSymbols.scala
Outdated
Show resolved
Hide resolved
| case JAVA_ACC_ABSTRACT => if (isClass) ABSTRACT else DEFERRED | ||
| case JAVA_ACC_INTERFACE => TRAIT | INTERFACE | ABSTRACT | ||
| case JAVA_ACC_ENUM => JAVA_ENUM | ||
| case JAVA_ACC_ENUM => if (isClass) JAVA_ENUM | SEALED else JAVA_ENUM |
There was a problem hiding this comment.
Here I don't follow, when is isClass true, when is it false?
There was a problem hiding this comment.
The enum member fields get the flag. (I believe I did not imagine that.)
51ce3e8 to
9294fba
Compare
9294fba to
11db53c
Compare
|
Updated with two suggestions. (Edit: and rebased) In the beginning, I expected to be calling That is not in proportion to the degree of suffering required. Also adjusted indentation on the flag translation, so that it fits in my default terminal. Reluctantly renamed variable I did not squash the two commits, but I did squash the two amendments. Dangerous to do before finishing first coffee! After deleting the package object, it tried to leak back into the second commit. ("How does git actually work again?") |
lrytz
left a comment
There was a problem hiding this comment.
Reluctantly renamed variable
abbietohasAbstractFlag(change not explicitly requested).
I like sentimental codebases
### What changes were proposed in this pull request? This pr aims to upgrade Scala from 2.13.11 to 2.13.12. Additionally, this pr adds ``-Wconf:msg=legacy-binding:s`` to suppress similar compiler warnings as below: ``` [ERROR] /Users/yangjie01/SourceCode/git/spark-mine-13/core/src/main/scala/org/apache/spark/deploy/client/StandaloneAppClient.scala:171: reference to stop is ambiguous; it is both defined in the enclosing class StandaloneAppClient and inherited in the enclosing class ClientEndpoint as method stop (defined in trait RpcEndpoint, inherited through parent trait ThreadSafeRpcEndpoint) In Scala 2, symbols inherited from a superclass shadow symbols defined in an outer scope. Such references are ambiguous in Scala 3. To continue using the inherited symbol, write `this.stop`. Or use `-Wconf:msg=legacy-binding:s` to silence this warning. [quickfixable] Applicable -Wconf / nowarn filters for this fatal warning: msg=<part of the message>, cat=other, site=org.apache.spark.deploy.client.StandaloneAppClient.ClientEndpoint.receive ``` ### Why are the changes needed? The new version bring some regression fixes: - scala/scala#10422 - scala/scala#10424 And a new feature: Quickfixes ``` For some errors and warnings, the compiler now suggests an edit that could fix the issue. Tooling such as IDEs can then offer the edits, or the compiler itself will make the change if run again with -quickfix. ``` - scala/scala#10406 - scala/scala#10482 - scala/scala#10484 The release notes as follows: - https://github.com/scala/scala/releases/tag/v2.13.12 ### Does this PR introduce _any_ user-facing change? Yes, Scala version changed. ### How was this patch tested? Pass Github ### Was this patch authored or co-authored using generative AI tooling? NO Closes #43185 from LuciferYang/SPARK-45331. Authored-by: yangjie01 <yangjie01@baidu.com> Signed-off-by: Dongjoon Hyun <dhyun@apple.com>
Fixes scala/bug#12800
In the current scheme, an enum should be
sealed abstractand have only its elements as "children".If an enum element has a body, then permittedSubclasses includes the element subclass.
The two tweaks are: don't add those permittedSubclasses as children; set
sealed abstractunconditionally (on parsing an enum field, where the enum is already marked sealed).The symptoms were that patmat would warn about
MyEnum$1(where the anon subclass is a child) orMyEnum forSome not in X,Y,Z(if the enum is not marked abstract).Second commit expunges the kludge of making enum always abstract just for exhaustivity. Instead, patmat analysis checks for an enum class (
isSealedEnum). Class file parser assumes only present flags, exceptACC_ENUMis translated to includeSEALEDfor classes. Java parser checks enum members for a deferred member, and setsABSTRACTaccordingly.