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

Match exhaustivity is broken when case class contains java enum field #15179

Closed
WojciechMazur opened this issue May 13, 2022 · 6 comments
Closed

Comments

@WojciechMazur
Copy link
Contributor

WojciechMazur commented May 13, 2022

Compiler version

3.1.3-RC3
When testing in the source project (link below) if fails with 3.1.2 also, works correctly with 3.1.1

Minimized code

Based on https://github.com/kirill5k/mongo4cats/blob/ed6a5c112c16e71af2557efa9f4e5f45f9a63551/core/src/main/scala/mongo4cats/collection/queries/WatchQueryBuilder.scala#L125-L137

FullDocument.java

package changestream;

public enum FullDocument {
    DEFAULT("default"),
    UPDATE_LOOKUP("updateLookup"),
    WHEN_AVAILABLE("whenAvailable"),
    REQUIRED("required");

    private final String value;
    FullDocument(final String caseFirst) {
        this.value = caseFirst;
    }
}

QueryCommand.scala

package queries

sealed private[queries] trait QueryCommand

private[queries] object QueryCommand {
  final private[queries] case class FullDocument(fullDocument: changestream.FullDocument)       extends QueryCommand
  final private[queries] case class AllowDiskUse(allowDiskUse: Boolean)                         extends QueryCommand
  final private[queries] case class BypassDocumentValidation(bypassDocumentValidation: Boolean) extends QueryCommand
}

test.scala

//> using scala "3.1.3-RC3"

package queries

def test() =
  val command: queries.QueryCommand = ???
  command match {
    case QueryCommand.FullDocument(doc) => ???
    case QueryCommand.AllowDiskUse(v)   => ???
    case _ => ???
  }
javac -d . FullDocument.java  
./bin/scalac QueryCommand.scala test.scala

Reproducing with scala-cli for different Scala version is not determistic - might or might not give a warning

Output

-- [E030] Match case Unreachable Warning: test.scala:9:9 ----------------------------------------------------------------------------------------
9 |    case QueryCommand.FullDocument(doc) => ???
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |         Unreachable case
1 warning found

Expectation

Compiler should know give an incorrect exhaustivity warning

@WojciechMazur WojciechMazur added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels May 13, 2022
@bishabosha
Copy link
Member

I think this should have been fixed by #15109, could you try with a nightly?

@bishabosha bishabosha added area:pattern-matching and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels May 13, 2022
@WojciechMazur
Copy link
Contributor Author

I've also had a similar issue when compiling another project with 3.2.0-RC1 nightly, but it was not using java classes and I was not able to minimize it outside the project.
https://github.com/gemini-hlsw/gsp-graphql/blob/3c14c0ed2827c334e7d1c875afbc081bf0d1ebe1/modules/sql/src/main/scala/SqlMapping.scala#L1799-L1804

Simplified snippet given a warning, but only in that project.

  def x: SqlDiscriminatedType = ???
  val ctpe = Some(x) match {
     case Some(discriminator) => ???
     case _ => ???
  }

Output:
[info] compiling 9 Scala sources to /home/wmazur/projects/virtuslab/dotty-community/gsp-graphql/modules/sql/target/scala-3.1.2/classes ...
[error] -- [E030] Match case Unreachable Error: /home/wmazur/projects/virtuslab/dotty-community/gsp-graphql/modules/sql/src/main/scala/SqlMapping.scala:1803:19 
[error] 1803 |          case Some(discriminator) => ???
[error]      |               ^^^^^^^^^^^^^^^^^^^
[error]      |               Unreachable case
[error] one error found

@WojciechMazur
Copy link
Contributor Author

WojciechMazur commented May 13, 2022

@bishabosha I've run it now with 3.2.0-RC1-bin-SNAPSHOT-git-9dbe2d3 and it seems to work. The snippet from the previous comment was not tested yet.
@Kordyjan should we prepare for 3.1.3-RC4 with regression fixes cherry-picked from the current main?

@Kordyjan Kordyjan added the backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. label May 16, 2022
@Kordyjan
Copy link
Contributor

Am I reading it correctly?

3.1.1         -> OK
3.1.2         -> broken
3.1.3-RC3     -> broken
3.2.0-nighlty -> OK

@Kordyjan Kordyjan removed the backport:nominated If we agree to backport this PR, replace this tag with "backport:accepted", otherwise delete it. label May 16, 2022
@WojciechMazur
Copy link
Contributor Author

@Kordyjan yes, this is correct, it seems to be broken in 3.1.2 and 3.1.3-RC3

@dwijnand
Copy link
Member

Just for context, the "breakage" in [3.1.2,3.2.0) comes from my fix to the warning emission (which wasn't stable before: unrelated changes would cause untouched warnings from be emitted).

@Kordyjan Kordyjan added this to the 3.1.3 milestone May 16, 2022
@Kordyjan Kordyjan removed this from the 3.1.3 milestone May 31, 2022
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

4 participants