profile
viewpoint
Dale Wijnand dwijnand @lightbend London, UK https://twitter.com/dwijnand @scala & @sbt maintainer at @lightbend. Interested in FP, tooling, & API/library design. Ex @rust-lang's Cargo+Rustup, & @playframework + @lagom maintainer.

dotty-staging/dotty 75

Research platform for new language concepts and compiler technologies for Scala.

dwijnand/abactis 0

Manages logging and auditing of the data in Consul KV

dwijnand/advisoryboard 0

Scala Center Advisory Board planning

dwijnand/akka 0

Build highly concurrent, distributed, and resilient message-driven applications on the JVM

dwijnand/akka-grpc 0

Akka gRPC

dwijnand/akka-grpc-play-quickstart-java 0

Example for akka-grpc services embedded in Play framework applications

dwijnand/akka-http 0

The Streaming-first HTTP server/module of Akka

dwijnand/akka-persistence-cassandra 0

A replicated Akka Persistence journal backed by Apache Cassandra

push eventdwijnand/shisa

Dale Wijnand

commit sha 241e9ac372d2e0de73e9d434c84c4d2754798d28

Wrap

view details

push time in 3 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha f8d5d28b2c469fdee47922cd54b1554d30f6ec5e

Compact

view details

Dale Wijnand

commit sha 251d8baf9fea85509fe6db9ac1f290f04833e6ed

Corrections

view details

push time in 3 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha 30e55819519b56fc4995d6115a8e12a952d2533b

Compact

view details

Dale Wijnand

commit sha 8f4629035ad7bc789b777a31917f423a6a896c34

Corrections

view details

push time in 3 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha aa0bc4bf59b580426a3dad3c528e2a8c5bb463cb

Dedupe non-VC/VC

view details

push time in 6 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha 38bf41aed168f4ac71eccce0ae6e80ef62659226

Actually use the new virtual switch_vc

view details

push time in 7 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha 6f48cf3526bebb102837a84af67f2b0b140de526

Compact

view details

Dale Wijnand

commit sha 258419ab403abeb87b4463d9f9cf43833784053f

Virtualise switch_vc

view details

push time in 7 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha ef8577a5737d262d7002b9c5d6e85303345be57a

Start to break down expected msgs by val

view details

Dale Wijnand

commit sha c445443e8284e0fe9e98b8ec233369fc6301c83d

Fix "override val contents"

view details

Dale Wijnand

commit sha b4186a5c5157adcf7c0d3763b496cf91f7f8a923

Drop summary/count

view details

Dale Wijnand

commit sha ac2537e840148e08b9771074f103710932cd653a

Fix OB1 error in scalac3 lineNo

view details

Dale Wijnand

commit sha bcbef1d50bc0dc5f64a2fb059192f613d487a416

Port Call.meth_p/prop_m

view details

Dale Wijnand

commit sha 6d8e2107f0bb8b028815c8bfdd4b64c63bea9183

Virtualise {m2p,p2m}_{m,p}

view details

push time in 9 hours

push eventdwijnand/shisa

Dale Wijnand

commit sha 5be8d55684bf241d9f88ea843d68f59affaff122

Shuffle

view details

Dale Wijnand

commit sha dd538f3cd85376c7585082e2003d1a7ce73ee6ea

Give hashHash expected messages

view details

push time in a day

delete branch dwijnand/shisa

delete branch : gen-files

delete time in a day

push eventdwijnand/shisa

Dale Wijnand

commit sha 0777a1eec640b15aca7f14ee249a4f2475cf2233

Start to generate the test files

view details

Dale Wijnand

commit sha e3ea96b6d7e954d7743a93a8e30ae2b5bedfcf49

Move out Call_##

view details

Dale Wijnand

commit sha ea0b0183cac2764a912481ed1292f876fd66fbcf

Generalise Call_##

view details

Dale Wijnand

commit sha 29c52c8d7787858c346268d2e0ecad19e1e8323c

Move to testdata so can test for gen source

view details

Dale Wijnand

commit sha ae5900127bfb05d5c8a28c78a91b0781d1c2bb6f

Generate Call_pos

view details

Dale Wijnand

commit sha 8a7078a4892ab3277933d84393494ea621197fc4

Test Call_pos_expected

view details

Dale Wijnand

commit sha 9fca6c061cc64c345873c8b104ac75f7fdbd3632

Generalise Call_pos some more

view details

Dale Wijnand

commit sha c99ff6afd65800f171e4d84d445d0f3d977b2b45

Add back args handling + missing printing + files printing + introduce MkInMemoryTestFile

view details

Dale Wijnand

commit sha 1325e9ab0044f9ae2f79e427994acc5a92c5c2d4

Merge Call gen files, start to reason on them

view details

Dale Wijnand

commit sha fd333d991c74952bc98bf0abd97c841c32ecad29

Extract altName

view details

Dale Wijnand

commit sha e9174dfb11edf73c9a2904c0714f27253700d63d

Move {obj,str}.##() to Call.##! Win

view details

Dale Wijnand

commit sha f7e5dc55f5ce3ba452d2b3b918273a1d80144476

Make Call more and more composable

view details

Dale Wijnand

commit sha 18d6a2e4472341551ce8b4974fcbe64b58adca6a

Move MkInMemoryTestFile back in

view details

Dale Wijnand

commit sha 6afe6dfa562970782f47f26781a632b238562725

Might as well make innerPrelude blocks too

view details

Dale Wijnand

commit sha 20f1e991a9f5b4d6062b7da9a6fc64c7f5d2bd50

Fix exists/delete path

view details

Dale Wijnand

commit sha 408a310d421e90a2a16a6cf07426bdf210e79cc3

New versions

view details

Dale Wijnand

commit sha 18ea839ac46937b11d95b1abdf55e5bffc6f6f47

Versions & add Cats (for Chain)

view details

Dale Wijnand

commit sha 4ff04a6e35b0b48951ea477b5b6feb039aea6d3f

Start to purify

view details

Dale Wijnand

commit sha c689f582d50bcc92d33a17db90adf619261df672

Kill file.chk

view details

Dale Wijnand

commit sha adc0e01f06b071a8f92f12f3a155504e620624d7

Introduce file.writeLines

view details

push time in a day

PullRequestReviewEvent

push eventdwijnand/scala-runners

Daiki Ogawa

commit sha 30fad6ad0d5ba5f5f1d0fa23471c54d71d542fe2

Fix /dev/null redirection process Related resources: - https://mywiki.wooledge.org/BashFAQ/055

view details

Daiki Ogawa

commit sha fef44a85cdfd09ece6a1fc35d4b6938e78c6feed

Fix `/dev/null` to `>/dev/null`

view details

Dale Wijnand

commit sha af5995ed99026daeaca4f96be24e0189c5444cef

Merge pull request #27 from d-ogxwx/fix-null-redirection

view details

push time in 2 days

PR merged dwijnand/scala-runners

Fix /dev/null redirection process

Related resources:

  • https://mywiki.wooledge.org/BashFAQ/055
+1 -1

3 comments

1 changed file

d-ogxwx

pr closed time in 2 days

pull request commentscala/scala

Clean up warnings in compiler module

The analysis isn't always the same because of the use of HashSet/HashMap (for performance over Linked*).

NthPortal

comment created time in 2 days

pull request commentscala/community-build

2.12: new Scala SHA

Yeah https://github.com/ghik/silencer/pull/33

SethTisue

comment created time in 2 days

push eventscala/scala

Dale Wijnand

commit sha 3b5c12d366e6c7083e6d6c8d18f6ac09a44f5c66

Allow forks to run bootstrapped tests on Travis CI

view details

Dale Wijnand

commit sha b62b5066d7f200e10d0c10fc163d27723f3fee33

Merge pull request #9268 from dwijnand/build/allow-forks Allow forks to run bootstrapped tests on Travis CI

view details

push time in 2 days

delete branch dwijnand/scala

delete branch : build/allow-forks

delete time in 2 days

PR merged scala/scala

Allow forks to run bootstrapped tests on Travis CI internal

Makes use of Travis CI's Workspaces feature: https://docs.travis-ci.com/user/using-workspaces.

Fixes https://github.com/scala/scala-dev/issues/663

+147 -102

6 comments

5 changed files

dwijnand

pr closed time in 2 days

issue closedscala/scala-dev

Travis-CI config doesn't work from forks

some contributors might appreciate being able to run PR validation in their forks, for work that isn't ready for the main scala/Scala PR queue

@dwijnand made a brief initial stab at https://github.com/scala/scala/pull/8665 but quickly realized it needed more work

closed time in 2 days

SethTisue

Pull request review commentscala/scala

Clean up warnings in compiler module

 lazy val compiler = configureAsSubproject(project)         --- (base ** "Scaladoc*ModelTest.scala") // exclude test classes that depend on partest       ).get     },-    Compile / scalacOptions += "-Xlint:-deprecation,-inaccessible,-nonlocal-return,-valpattern,-doc-detached,_",+    Compile / scalacOptions ++= Seq(+      "-Xlint",+      "-feature",+      "-Wconf:cat=deprecation&msg=early initializers:s", // compiler heavily relies upon early initializers+      "-Wconf:msg=match may not be exhaustive:i",

yep

NthPortal

comment created time in 2 days

PullRequestReviewEvent

pull request commentdwijnand/scala-runners

Fix /dev/null redirection process

Thanks, @d-ogxwx. Thanks for spotting the problem. I recently learnt about this craziness.. But I think Seth's right, you chopped off an extra >.

d-ogxwx

comment created time in 2 days

push eventlightbend/mima

Scala Steward

commit sha f7ccf998f6e48c2f6bece0fd825daf9d3cd80519

Update coursier to 2.0.5

view details

Dale Wijnand

commit sha 7620439ecb6abef86de920c461d5b367a86e8b27

Merge pull request #571 from scala-steward/update/coursier-2.0.5 Update coursier to 2.0.5

view details

push time in 2 days

PR merged lightbend/mima

Update coursier to 2.0.5

Updates io.get-coursier:coursier from 2.0.4 to 2.0.5. GitHub Release Notes - Version Diff

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

<details> <summary>Ignore future updates</summary>

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "io.get-coursier", artifactId = "coursier" } ]

</details>

labels: library-update, semver-patch

+1 -1

0 comment

1 changed file

scala-steward

pr closed time in 2 days

pull request commentscala/scala

Disable fatal warnings in the library

Yep, didn't think of that, thought we were blocked on re-STARR'ing and having access to the opt-outs. 👍

dwijnand

comment created time in 2 days

pull request commentscala/scala

Allow forks to run bootstrapped tests on Travis CI

Detailed restarrFull and restarr while I was hanging out in README.md.

dwijnand

comment created time in 2 days

push eventdwijnand/scala

Dale Wijnand

commit sha 3b5c12d366e6c7083e6d6c8d18f6ac09a44f5c66

Allow forks to run bootstrapped tests on Travis CI

view details

push time in 2 days

pull request commentscala/scala

Clean up warnings in reflect module

Not labeled internal because there are some user-facing deprecations.

NthPortal

comment created time in 2 days

issue commentscala/scala-dev

investigate: error events in jfr recording

Keep open?

lrytz

comment created time in 2 days

issue closedscala/scala-dev

provide hooks for CI environment outside of version control

... since they are subject to forces outside of version control

use case: being able to bump the EC2 instance type to get more RAM/CPU without breaking all pending PRs because partest runs out of ram in this new environment. We should not have to depend on everyone rebasing on our latest fix to counter-act these changes, so that means that e.g., concurrency and Java heap sizing should be configurable using environment vars?

closed time in 2 days

adriaanm

issue commentscala/scala-dev

provide hooks for CI environment outside of version control

Seems hard and at the same time not a problem these days - Seth Tisue.

adriaanm

comment created time in 2 days

issue closedscala/scala-dev

JUnit resident compiler bug / cross-talk between tests

The following two tests in scala.lang.traits.BytecodeTest:

  @Test
  def eins(): Unit = {
    val code =
      """class A
        |class B extends A
        |class C extends B
      """.stripMargin
    compileClasses(code)
  }

  @Test
  def zwei(): Unit = {
    val jCode = List("interface A { }" -> "A.java")
    val code1 =
      """trait B extends A
        |class C extends B
      """.stripMargin
    compileClasses(code1, jCode)
  }

Individually they both run fine. When running them together (first eins, then zwei), we get

java.lang.AssertionError: assertion failed: The compiler issued non-allowed warnings or errors:
pos: source-unitTestSource.scala,line-2,offset=34 illegal inheritance; superclass Object
 is not a subclass of the supertrait A
 of the mixin trait B ERROR

    at scala.Predef$.assert(Predef.scala:219)
    at scala.tools.testing.Compiler.checkReport(BytecodeTesting.scala:45)
    at scala.tools.testing.Compiler.compileToBytes(BytecodeTesting.scala:52)
    at scala.tools.testing.Compiler.compileClasses(BytecodeTesting.scala:57)
    at scala.lang.traits.BytecodeTest.zwei(BytecodeTest.scala:262)

Renaming B to B1 in test zwei fixes the cross-talk. Possibly related to https://github.com/scala/scala/commit/59d6dbc.

closed time in 2 days

lrytz

issue commentscala/scala-dev

JUnit resident compiler bug / cross-talk between tests

Optimistically closing that this was fixed in the rework that was https://github.com/scala/scala-partest/issues/75.

lrytz

comment created time in 2 days

Pull request review commentscala/scala

Allow forks to run bootstrapped tests on Travis CI

 jobs:           - triggerScalaDist           - sbt -Dscala.build.compileWithDotty=true library/compile -      # pull request validation (w/ mini-bootstrap)-      # "mini" in these senses:-      # - it doesn't use the complicated legacy scripts.-      # - it doesn't publish to scala-pr-validation-snapshots-      #   (because we need secrets for that and Travis-CI doesn't give PR jobs access to secrets)-      # it is still a true bootstrap.+      # pull request validation (w/ bootstrap)+      # differs from the bootstrap above by:+      # - not using bash script setup, but just the underlying sbt calls+      # - publishing locally rather than to Artifactory       - stage: build-        name: "JDK 8 pr validation"-        if: type = pull_request+        name: bootstrap and publishLocal+        if: type = pull_request OR repo != scala/scala+        script: sbt -warn setupPublishCore generateBuildCharacterPropertiesFile headerCheck publishLocal+        workspaces:+          create:+            name: published-local+            paths:+              - "$PWD/buildcharacter.properties"+              - "$HOME/.ivy2/local/org.scala-lang"++      - stage: testAll+        name: testAll1+        if: type = pull_request OR repo != scala/scala+        workspaces:+          use: published-local         script:-          - set -e-          - sbt -warn setupPublishCore generateBuildCharacterPropertiesFile headerCheck publishLocal-          - STARR=`cat buildcharacter.properties | grep ^maven.version.number | cut -d= -f2` && echo $STARR-          - sbt -Dstarr.version=$STARR -warn setupValidateTest test:compile info testAll+          - STARR=$(sed -n 's/^maven\.version\.number=//p' buildcharacter.properties) && echo $STARR+          - sbt -Dstarr.version=$STARR -warn setupValidateTest test:compile info testAll1

Keep OSGI testing, in PR validation.

dwijnand

comment created time in 2 days

PullRequestReviewEvent

push eventscala/scala

Dale Wijnand

commit sha 18778ecfe11b3a485c0ed6e68ba74618638cb88f

Fix run/t12182, avoid exhaustivity warnings

view details

push time in 2 days

push eventscala/scala

Jason Zaugg

commit sha c7ebfdbf4df6b59f0d9698f20681171a0de9120b

SI-5365 Check exhaustivity with guards, extractors Rather than disabling the analysis altogether, rewrite guard to `true` (by default) or to `false` under a new compiler option. The default option errs on the side of avoiding spurious warnings where the guard writer knows better. However, there was a convincing argument made in the ticket that in these cases it would not be to onerous to require the code to be rewritten from case P if g1 => case P if g2 => to: case P if g1 => case P => Or to: (scrut: @unchecked) match { case P if g1 => case P if g2 => So perhaps we can turn on the strict version by default, after running against the community build as a sanity check. Extractor patterns had the same limitation as guards. This commit also enables the analysis for them in the same way as done for guards. However, this still not done for `unapplySeq` extractors, as the counter example generator can't handle these yet.

view details

Greg Pfeil

commit sha c02a234cc9b0ac8e80d6d45537cbcddb04f14e36

Exhaustivity with extractors and unsealed traits.

view details

Greg Pfeil

commit sha 2da20d437744e001ed2bbff553c73b192b75eaaf

Update exhaustivity checking. Handle exhaustivity for `unapplySeq` extractors and restrict a `WildcardExample` case to when strict pattern matching is enabled.

view details

Dale Wijnand

commit sha e8734c1a652557b2c98483c67da28a333d159bc7

Avoid exhaustive warnings in try/catch

view details

Dale Wijnand

commit sha 03574d889aa5ec70d8061a05be5b5b0f682540df

Check exhaustivity of case class unapplySeq extractors too ProductExtractorTreeMaker handles non-custom extractors, i.e. the synthetic ones generates for case classes. I think this case was just accidentally missing from the original commit. The change to run/virtpatmat_unapplyprod makes sense to me - it's an inexhaustive match, albeit with complicated counter-examples... :( This is the actually the last remaining tree maker, so none will back off after this, from my reading - but I kept the back-off stuff as is, keeping the diff minimal, to try to land this as easily as possible.

view details

Dale Wijnand

commit sha df6b7f2989b95fe937bc515fe14fde41462de46e

Fix the List rewrite in patmat to use 2.13's UnapplySeqWrapper I didn't double-check, but what I expect happened is that all the pattern matches that included a "case List()" stopped producing any exhaustivity/unreachable warnings. And then my guess is the impact wasn't understood and the checkfiles were just updated? In the next commit strict pattern matching becomes the default, which, when bootstrapping, found a pattern match in the compiler that uses "case List()" (with -Werror enabled).

view details

Dale Wijnand

commit sha c54081e75015c4490ade0787ebe45936731e2747

Always check exhaustivity of custom extractors/guards

view details

Dale Wijnand

commit sha 9519ebe36dc68e31bf28e775c15be9554175f6f4

Drop gnomic "It would fail on the following input: _"

view details

Dale Wijnand

commit sha cb391c292a58bfda66abf717c39e8ed45715017e

Make sure counter-examples are distinct With exhaustivity not being skipped for TreeMakers, we're running into more counter-examples which seem to be getting by our CounterExample.prune, so add an extra string distinct to keep run/patmatnew.scala stable.

view details

Dale Wijnand

commit sha 0416c57a01a2b0feafc340893d64cd54ca7ae84c

Reverse -Xlint:strict-unsealed-patmat into -Xno-unsealed-patmat-analysis

view details

Dale Wijnand

commit sha 4ef23e4056f67eddc11b6dddd154e935b2a7c29e

Avoid spurious custom extractor warnings The pattern matcher converts code like: Box(Option("hello")) match { case Box(Some(s)) => case Box(None) => } into two invocations of Box.unapply, because it can't trust that Box.unapply is idempotent. For case classes (like Some) it can, and moreso it can just access the underlying values directly ("x1.value"). The exhaustivity/unreachability analysis builds on this (e.g "pointsToBound.exists(sym => t.exists(_.symbol == sym)"). With the previous commits making the exhaustivity/unreachability checker consider custom extractors this would result in multiple symbols for each extraction (instead of all being "x1.value", for example) which results in multiple SAT variables which results, basically, in warnings that the value returned from the first extraction could None and the second value could be Some - which is only true for a non-idempotent Box.unapply. The intent of the previous commits (and the whole PR) is to make the exhaustivity checker provide warnings that were previous missing, but warning for fear of non-idempotent custom extractors would produce more noise than signal. Now, within a minor release like 2.13.4 we can't go and change the code generation and thus the code semantics (Dotty can and apparently does), but we can do the analysis with the assumption of idempotency. That's what this does: in MatchApproximator's TreeMakersToProps use a cache for the binders so when we see two extractions that are equivalent we reuse the same binder, so it translates into the same SAT variable.

view details

Dale Wijnand

commit sha ac2c3c87b67f29175ff9655cdcfcb30eca96a6a4

Implement -Xnon-strict-patmat-analysis

view details

Dale Wijnand

commit sha 3808a6ac5d3d16d0bcb37f9bb9bd623ca364fc52

Mention reachability warnings on `@unchecked`

view details

Dale Wijnand

commit sha 1ac95fd9b1d1ad93e03148df2a48da0e544151e7

Merge pull request #9140 from dwijnand/exhaust

view details

push time in 2 days

delete branch dwijnand/scala

delete branch : exhaust

delete time in 2 days

PR merged scala/scala

Exhaustivity of extractors/guards/unsealed but not try/catch prio:blocker release-notes

Description

The accuracy of exhaustivity checking for pattern matches is improved. These changes intend to bring to light pattern matching code that might throw runtime MatchErrors for unhandled cases, without any indication at compile time.

Most importantly:

  1. guards no longer disable exhaustivity checking (fixing scala/bug#5365)
  2. refutable custom extractors also no longer disable exhaustivity checking
  3. under -Xlint:strict-unsealed-patmat, matches on unsealed types are checked for exhaustivity too

As before, it remains possible to disable checking of both exhaustivity and reachability by annotating an expression with @unchecked, such as (foo: @unchecked) match { ... }.

But you may also use -Xnon-strict-patmat-analysis to disable the "strict" pattern matching for guards (1) and custom extractors (2) or -Xno-unsealed-patmat-analysis to disable the checking of unsealed types (3).

Guards

Guards no longer disable the exhaustivity checker. Rather, the checker checks for exhaustivity using the "pessimistic" assumption that the guard may be false.

Thus, given the following example:

x match {
  case p if g1 => ...
  case p if g2 => ...
  case p if g3 => ...
}

The change decided is that, even if the user may know or be able to determine that one of g1, g2 and g3 will always be true (at least one), it's safer for the exhaustivity checker to not back off even if it means it will produce a warning here, requiring the user to suppress the warning by either:

  1. dropping the final if g3; or
  2. adding a default case (case x => ... or case _ => ...) with some body (perhaps throwing or logging)

Custom Extractors

Refutable custom extractors no longer disable exhaustivity checking. (Irrefutable ones already didn't disable it). It is “pessimistically” assumed that the extractor might not match.

An “irrefutable” custom extractor is one that returns Some rather than Option, such as:

object Length {
  def unapply(s: String): Some[Int] = Some(s.length)
}

So if you have custom extractors that are also irrefutable (that is they can't "not match") then you can resolve some exhaustivity warnings by making it return Some[..] rather than Option[..]. As an example:

scala> object Length { def unapply(s: String): Option[Int] = Some(s.length) }
object Length

scala> "abc" match { case Length(n) => println(s"The length was $n.") }
       ^
       warning: match may not be exhaustive.
The length was 3.

scala> object Length { def unapply(s: String): Some[Int] = Some(s.length) }
object Length

scala> "abc" match { case Length(n) => println(s"The length was $n.") }
The length was 3.

Unsealed types

Types that aren't sealed are no longer exempt from exhaustivity checking. This makes pattern matching safer, as the compiler will now give a warning when it can't see that a pattern covers all the cases, rather than quietly disabling the check.

Known Issues/Limitations

The counter-examples provided may not always be clear, particularly around unapplySeq. For example it might say something like Chain() as an attempt to say that some values of type Chain aren't covered by the Chain.unapplySeq usage.

https://github.com/scala/bug/issues/10502 the exhaustivity analysis is overly-optimistic about irrefutable custom extractors, not considering whether their sub-pattern is covered or not. For example case Perhaps(Right(1)) would fail to identify that there are values such as Left(_) or Right(x) forSome x != 1 that aren't covered (assuming that Perhaps.unapply is an irrefutable "extractor" that just wraps the input in an irrefutable Some).

https://github.com/scala/bug/issues/12186 In some patterns, like type patterns, aliases of case objects (and possible case classes too) won't dealias and so won't register as exhausting the match, such as case _: Nil.type => (with Nil being the val alias Nil in Predef rather than the case object in scala.collection.immutable).

We hope to resolve these soon... (🤞)

Migration

The best-case scenario is that the matcher identifies holes in the match that were previously ignored, so these can be addressed by the programmer.

Where it is expected that some values will throw, you can get rid of the warning by explicitly defining a default case (case x => ... or case _ => ...), perhaps throwing a more specific exception with some more domain-specific information or recovering in some way.

You might also choose the (sometimes) terser route of annotating some non-total pattern match by adding @unchecked as mentioned above.

Provenance

This PR was originally:

  • a continuation of @retronym’s and @sellout's work in #5617
  • which @milessabin had made accessible as a part of Typelevel Scala 2.12.1 (notes)

Fixes scala/bug#5365 Fixes scala/bug#8178 Fixes scala/bug#9232

+1206 -229

27 comments

191 changed files

dwijnand

pr closed time in 2 days

issue closedscala/bug

unapplySeq silences all exhaustivity warnings

The following code compiles without any warning:

package test

final class Foo(val value: Int)
object Foo {
  def unapplySeq(foo: Foo): Some[Seq[Int]] = Some(List(foo.value))
  /*def unapply(foo: Foo): Some[Int] = Some(foo.value)*/
}

sealed trait Tree
case class Node1(foo: Foo) extends Tree
case class Node2() extends Tree

object Test {
  def transformTree(tree: Tree): Any = tree match {
    case Node1(Foo(1)) => ???
  }
}

But if you uncomment unapply, you get:

test2.scala:14: warning: match may not be exhaustive.
It would fail on the following inputs: Node1(_), Node2()
  def transformTree(tree: Tree): Any = tree match {
                                       ^
one warning found

It'd be nice to give the same warnings when only unapplySeq is used, for example with List.

closed time in 2 days

scabug

issue closedscala/bug

Case class with varargs defeats exhaustiveness matching

Including a case class with varargs in the constructor seems to prevent exhaustiveness checking from happening.

sealed trait Fails
case class VarArgs1(a: String*) extends Fails
case class FailsChild2(a: Seq[String]) extends Fails
object FailsTest {
  def matchOnVarArgsFirstFails(f: Fails) {
    f match {
      case VarArgs1(_) => ???
      // BUG: Without this line we should get a non-exhaustive match compiler error. 
      //case FailsChild2(_) => ???
    }
  }

  def matchOnSeqArgsFirstWorks(f: Fails) {
    f match {
      case FailsChild2(_) => ???
      // Without this line, the compiler reports a "match may not be exhaustive" error as expected.
      case VarArgs1(_) => ???
    }
  }
}

sealed trait Works
case class SeqArgs1(a: Seq[String]) extends Works
case class SeqArgs2(a: Seq[String]) extends Works
object WorksTest {
  def matcher(f: Works) {
    f match {
      case SeqArgs1(_) => ???
      // Without this line, the compiler reports a "match may not be exhaustive" error as expected.
      case SeqArgs2(_) => ???
    }
  }
}

closed time in 2 days

scabug

issue closedscala/bug

Match Exhaustiveness Testing Ignores Guard Statements

It seems that guarded match expressions are not tested for completeness at compile time. Or, more accurately, it seems that guarded case statements are optimistically considered complete. For example, the following code will compile without "warning: match is not exhaustive!", even though calling it with a value of 1 will result in a MatchError.

def foo(x: Option[Int]): Int = x match {
  case Some(n) if n % 2 == 0 => n
  case None => 0
}

The equivalent code in Ocaml does print a non-exhaustive match warning at compile time.

let foo(x) = 
  match x with
  | Some n when n mod 2 = 0 -> n
  | None -> 0;;


Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
Some _
(However, some guarded clause may match this value.)
val foo : int option -> int = <fun>

Obviously the compiler can't decide whether or not arbitrary combinations of guards are complete, but I was surprised didn't treat guards pessimistically like Ocaml does. This actually bit us in production code, when a method like this:

def foo(x: Option[Int]): Int = x match {
  case Some(n) if n % 2 == 0 => n
  case _ => 0
}

was refactored to look like this:

def foo(x: Option[Int]): Int = x match {
  case Some(n) if n % 2 == 0 => n
  case None => 0
}

which resulted in runtime MatchErrors.

I understand that adding a warning that treats guarded match statements pessimistically could be annoying in cases when the combined guards actually are safe, but in these instances the warning could easily be dismissed with an annotation or a noop unguarded match. Why don't we give Scala users the option for added safety?

closed time in 2 days

scabug

pull request commentscala/scala

Clean up warnings in reflect module

Yeah, I reviewed it.

NthPortal

comment created time in 2 days

pull request commentscala/scala

Clean up warnings in compiler module

Looks like I messed up rebasing this. All yours, Princess.

NthPortal

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventNthPortal/scala

bjornregnell

commit sha 2b012729e963429823c095ae4890f2b1e83d5e0c

fix #11676 un-deprecate useful StringOps operations

view details

Kazuhiro Sera

commit sha 1aacda21e067e7a019798033b204c5db551836e7

Fix #12065 by adding scaladocs

view details

zerosum

commit sha 6112b18d27a595eca0b39e5bbbaa7f308a01aa95

Fixes https://github.com/scala/bug/issues/11805

view details

zerosum

commit sha f4e25d0313330f4772816d31e1453f65a8489fca

modify css path - https://github.com/scala/scala/pull/9252/files#r507672695

view details

Lukas Rytz

commit sha 57ae2a6cc6505d3b66be93a47b2cee938cce1aa3

Merge pull request #9252 from zerosum/issue/11805 Scaladoc member permalinks now get us to destination, not to neighbors

view details

Kazuhiro Sera

commit sha fff2b81b0c7fc1ce3616ba4c3c2308008bfe5672

Update a comment as suggested

view details

M.Shibuya

commit sha 84aed73cf8413e4d2020e6e422b09721db4916c3

Fix ArrayBuffer incorrectly reporting the upper bound in IndexOutOfBoundsException Fixes scala/bug#12176

view details

Georgi Krastev

commit sha 31a3f9921fb9e12af2ca734dcd20cdcc9c9a8451

Use correct tree for child unapply context Prevents `ClassCastException` in some GADT scenarios and makes valid code compile in others. The parent context tree could be the case def itself. In that case creating a child context with the same tree breaks the logic to restore saved type bounds in `typedCase`, because `enclosingCaseDef` returns the child instead of the parent. This leads to saving modified bounds in the child context but later trying and failing to restore them in the parent context. The leaked bounds later cause type errors in the best case or propagate incorrect information to erasure in the worst case. Using the tree of the unapply itself for the child context means that `enclosingCaseDef` will return the parent context.

view details

Mitsuhiro Shibuya

commit sha d47ea5bf7097b8070070bd30e98dd2351cadaa72

Test remove(Int) and remove(Int, Int) separately as suggested here: https://github.com/scala/scala/pull/9249#discussion_r508456058 Co-authored-by: Diego E. Alonso Blas <diesalbla@gmail.com>

view details

Lukas Rytz

commit sha 9faf48bd7a0132cfa03761b1aef8fc3225cc04db

Merge pull request #9254 from joroKr21/gadt-cce Use correct tree for child unapply context

view details

Som Snytt

commit sha 8e2f16e0abff06b1115d31762a9e6cb242a30b5d

Java imports compete with level 4 definitions Like Scala, an import in Java can shadow a definition in another file, if it is not import-on-demand. The implementation bailed too quickly from searching enclosing contexts while testing this condition.

view details

Som Snytt

commit sha 2878d88fca23fe2cb4b255bf978b87dc7164c114

Additional regression test

view details

NthPortal

commit sha 1390315b03bb32ffdfb1394b3ec6f4619faca1b8

[bug#3088][bug#12121] Fix adding/subtracting ListBuffer to/from itself Fix appending a `ListBuffer` to itself and subtracting a `ListBuffer` from itself. Fix appending a `Growable` that uses the default `addAll` implementation to itself.

view details

NthPortal

commit sha 8f6e522778f23e5b9a51d0b938ed6d20ea0f0d85

[bug#12009] Make ListBuffer's iterator fail-fast Make `ListBuffer`'s iterator fail-fast when the buffer is mutated after the iterator's creation. Co-authored-by: Jason Zaugg <jzaugg@gmail.com>

view details

Som Snytt

commit sha 71bce77a19a994f37659d9d163b26a4c967e279f

Use unmixed backticks more uniformly

view details

Princess | April

commit sha 9a716985fcfbb687a3b4cfe97e8eb1d88a65057d

Merge pull request #9174 from NthPortal/topic/mutation-tracking-iterators/PR [bug#12009] Make ListBuffer's iterator fail-fast

view details

Lukas Rytz

commit sha 7f6b956e1a49910abe6f47c2e6d2c690a8a4bdbc

Merge pull request #9255 from som-snytt/issue/12195

view details

Dale Wijnand

commit sha d7edb38b398825abde3ee16ecb35be27a6c34a18

Merge pull request #9256 from som-snytt/tweak/old-quotes

view details

Dale Wijnand

commit sha 4b8eea0c95caaf7c23cc8534a21a990cb8029200

Merge pull request #9249 from mshibuya/issue/12176

view details

Dale Wijnand

commit sha 6e96b92df4741e27ce9483e250f588a771097d07

Merge pull request #9251 from seratch/issue-12065

view details

push time in 2 days

push eventscala/scala

NthPortal

commit sha a9a712b896de70cee79d45c6fad8247098056137

Enable deprecation warnings for reflect build Enable deprecation warnings for reflect module build and fix or suppress all deprecations in the reflect module.

view details

NthPortal

commit sha 545ac8bd7ac876f49ef6e33b1b159b1fbeaa6c89

Enable feature warnings for reflect build Enable feature warnings for reflect module build and adjust places in the reflect module where features were used unnecessarily.

view details

NthPortal

commit sha d3085491c726d9aa0142e63418876aa019644d69

Remove remaining -Xlint exclusions from reflect build Remove remaining -Xlint exclusions from reflect build and suppress locations where -Xlint raised warnings.

view details

NthPortal

commit sha 9d6a2ebb1a7d453acf9c6b63623386e3cb630964

Enable -Werror for reflect build

view details

Dale Wijnand

commit sha 239bf73fdfb5d659d181f2e25f9879aab49f62e3

Disable fatal warnings in reflect ... in order to land this PR as well as the exhaustivity improvements PR.

view details

Dale Wijnand

commit sha 991ff8aa74cb5d7754420b9f381a9a242c3279f7

Merge pull request #9237 from NthPortal/topic/reflect-werror/PR

view details

push time in 2 days

PR merged scala/scala

Clean up warnings in reflect module

Follow-up to #9235

Not labeled internal because there are some user-facing deprecations.

+274 -153

0 comment

38 changed files

NthPortal

pr closed time in 2 days

issue closedscala/bug

Register allocation on local variable slots

Currently, scalac always uses a fresh local variable slot for each local, even if their scope doesn't overlap.

def f = {
  if (...) {
    val a = 0
    ...
  } else {
    val b = ""
    ..
  }
}

a and b could use the same local variable slot, which would make the method's frame smaller.

closed time in 2 days

retronym

delete branch dwijnand/scala

delete branch : revert-batching-global

delete time in 3 days

pull request commentscala/scala

Allow forks to run bootstrapped tests on Travis CI

I just realised that this also has the benefit of speeding up all Travis CI PR builds.

dwijnand

comment created time in 3 days

push eventdwijnand/scala

Dale Wijnand

commit sha ac2c3c87b67f29175ff9655cdcfcb30eca96a6a4

Implement -Xnon-strict-patmat-analysis

view details

Dale Wijnand

commit sha 3808a6ac5d3d16d0bcb37f9bb9bd623ca364fc52

Mention reachability warnings on `@unchecked`

view details

push time in 3 days

PR closed scala/scala

Introduces ExecutionContext.batchingGlobal and reverts ExecutionConte… library:concurrent

…xt.global to not be a BatchingExecutor

For discussion

+21 -10

3 comments

2 changed files

viktorklang

pr closed time in 3 days

pull request commentscala/scala

Introduces ExecutionContext.batchingGlobal and reverts ExecutionConte…

Superseded by #9270

viktorklang

comment created time in 3 days

PR opened scala/scala

Revert ExecutionContext.global to not be a BatchingExecutor

Fixes scala/bug#12089

+2 -10

0 comment

1 changed file

pr created time in 3 days

create barnchdwijnand/scala

branch : revert-batching-global

created branch time in 3 days

push eventdwijnand/scala

Dale Wijnand

commit sha 6062d3ccbf22cb8c321601d8082face30bfa91f6

Mention reachability warnings on `@unchecked`

view details

push time in 3 days

delete branch dwijnand/scala

delete branch : library-disable-fatal-warnings

delete time in 3 days

push eventscala/scala

Dale Wijnand

commit sha 6a5b2d975c8a3de161a0c8cd4c20110f997a2748

Disable fatal warnings in the library The fatal warnings PR (for library) was merged prematurely as it is impacting my exhaustivity PR. Rather do anything (like rebase or tweak) to the 12 commits that my PR consists of and therefore causing CI to rebuild each commit, I'm separately going to PR disabling fatal warnings, so I can merge my PR without it instantly breaking the 2.13.x branch. I'll do the same for the reflect and compiler PRs, and once we've re-STARR'd we can re-enable fatal warnings by either resolving all the exhaustivity warnings or opting out of them (or a mix of both).

view details

Dale Wijnand

commit sha 59c6eda13ce3e72b4d687658ef1ff7b5f0e1e44c

Merge pull request #9269 from dwijnand/library-disable-fatal-warnings Disable fatal warnings in the library

view details

push time in 3 days

PR merged scala/scala

Disable fatal warnings in the library

The fatal warnings PR (for library) was merged prematurely as it is impacting my exhaustivity PR (1). Rather do anything (like rebase or tweak) to the 12 commits that my PR consists of and therefore causing CI to rebuild each commit, I'm separately going to PR disabling fatal warnings, so I can merge my PR without it instantly breaking the 2.13.x branch.

I'll do the same for the reflect and compiler PRs, and once we've re-STARR'd we can re-enable fatal warnings by either resolving all the exhaustivity warnings or opting out of them (or a mix of both).

cc @NthPortal

+1 -0

0 comment

1 changed file

dwijnand

pr closed time in 3 days

push eventNthPortal/scala

NthPortal

commit sha 03437561922874e3d247aaff6ef54a00e8cfcd02

Enable -Werror for compiler build

view details

NthPortal

commit sha b04ea78a24632c44b675858da62fb97364f980ed

Un-deprecate some shadowing inner classes in compiler

view details

Dale Wijnand

commit sha 3ccf24948dbba00e89803b0b9a94459900f50a35

Disable fatal warnings in reflect & compiler This is to allow for this PR to land without clashing with the exhaustivity one - we'll converge in-tree, rather than have one PR have to wait/rebase on the other.

view details

push time in 3 days

push eventNthPortal/scala

Dale Wijnand

commit sha c5ac0faac934c0195b74e6dc4fd25612b507fca8

Avoid deprecated any2stringadd in RefChecks

view details

Dale Wijnand

commit sha 96cc33f0936c968b032f853877d1e1e6446ed7b3

Disable fatal warnings in reflect & compiler This is to allow for this PR to land without clashing with the exhaustivity one - we'll converge in-tree, rather than have one PR have to wait/rebase on the other.

view details

push time in 3 days

push eventNthPortal/scala

Dale Wijnand

commit sha 239bf73fdfb5d659d181f2e25f9879aab49f62e3

Disable fatal warnings in reflect ... in order to land this PR as well as the exhaustivity improvements PR.

view details

push time in 3 days

PullRequestReviewEvent

pull request commentscala/scala

Clean up warnings in compiler module

[error] /home/jenkins/workspace/scala-2.13.x-validate-main@3/src/compiler/scala/tools/nsc/typechecker/RefChecks.scala:1149:37: method any2stringadd in object Predef is deprecated (since 2.13.0): Implicit injection of + is deprecated. Convert to String to call +
[error]       def typesString = normalizeAll(qual.tpe.widen)+" and "+normalizeAll(other.tpe.widen)
[error]                                     ^
[error] one error found
[error] (compiler / Compile / compileIncremental) Compilation failed
NthPortal

comment created time in 3 days

push eventscala/scala

Seth Tisue

commit sha 8d3b2ca24002c3346856313510c83492bdd07412

update nightly build information in README.md fixing the issue reported at https://contributors.scala-lang.org/t/coming-soon-scala-2-13-4/4555/2 this also removes the bit about nightly Scaladoc, since that stopped in 2018 afaict

view details

Dale Wijnand

commit sha 1cc0a05e396150b32cf8a968e6822b5c937fe9ca

Merge pull request #9264 from SethTisue/readme-nightlies update nightly build information in README.md

view details

push time in 3 days

PR merged scala/scala

update nightly build information in README.md documentation internal

fixing the issue reported at https://contributors.scala-lang.org/t/coming-soon-scala-2-13-4/4555/2

this also removes the bit about nightly Scaladoc, since that stopped in 2018 afaict

+6 -10

0 comment

1 changed file

SethTisue

pr closed time in 3 days

push eventdwijnand/scala

Dale Wijnand

commit sha 4d6bddcc78d87dcf1362cab13a65a736eb58b213

Allow forks to run bootstrapped tests on Travis CI

view details

push time in 3 days

PR opened scala/scala

Disable fatal warnings in the library

The fatal warnings PR (for library) was merged prematurely as it is impacting my exhaustivity PR. Rather do anything (like rebase or tweak) to the 12 commits that my PR consists of and therefore causing CI to rebuild each commit, I'm separately going to PR disabling fatal warnings, so I can merge my PR without it instantly breaking the 2.13.x branch.

I'll do the same for the reflect and compiler PRs, and once we've re-STARR'd we can re-enable fatal warnings by either resolving all the exhaustivity warnings or opting out of them (or a mix of both).

cc @NthPortal

+1 -0

0 comment

1 changed file

pr created time in 3 days

create barnchdwijnand/scala

branch : library-disable-fatal-warnings

created branch time in 3 days

push eventlightbend/mima

Scala Steward

commit sha 28fbe0ac6ffaac9abed8d8d5afa0c6d546afa146

Update typesafe:config to 1.4.1

view details

Dale Wijnand

commit sha a619b31ca25027a7b6bf4dc4d0e0688bcd9ec2dc

Merge pull request #570 from scala-steward/update/typesafe-1.4.1 Update typesafe:config to 1.4.1

view details

push time in 3 days

PR merged lightbend/mima

Update typesafe:config to 1.4.1

Updates com.typesafe:config from 1.4.0 to 1.4.1. GitHub Release Notes - Version Diff - Version Diff

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

<details> <summary>Ignore future updates</summary>

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "com.typesafe", artifactId = "config" } ]

</details>

labels: library-update, semver-patch

+1 -1

0 comment

1 changed file

scala-steward

pr closed time in 3 days

PR opened scala/scala

Allow forks to run bootstrapped tests on Travis CI

Fixes https://github.com/scala/scala-dev/issues/663

+122 -60

0 comment

4 changed files

pr created time in 3 days

push eventdwijnand/scala

Dale Wijnand

commit sha 0416c57a01a2b0feafc340893d64cd54ca7ae84c

Reverse -Xlint:strict-unsealed-patmat into -Xno-unsealed-patmat-analysis

view details

Dale Wijnand

commit sha 4ef23e4056f67eddc11b6dddd154e935b2a7c29e

Avoid spurious custom extractor warnings The pattern matcher converts code like: Box(Option("hello")) match { case Box(Some(s)) => case Box(None) => } into two invocations of Box.unapply, because it can't trust that Box.unapply is idempotent. For case classes (like Some) it can, and moreso it can just access the underlying values directly ("x1.value"). The exhaustivity/unreachability analysis builds on this (e.g "pointsToBound.exists(sym => t.exists(_.symbol == sym)"). With the previous commits making the exhaustivity/unreachability checker consider custom extractors this would result in multiple symbols for each extraction (instead of all being "x1.value", for example) which results in multiple SAT variables which results, basically, in warnings that the value returned from the first extraction could None and the second value could be Some - which is only true for a non-idempotent Box.unapply. The intent of the previous commits (and the whole PR) is to make the exhaustivity checker provide warnings that were previous missing, but warning for fear of non-idempotent custom extractors would produce more noise than signal. Now, within a minor release like 2.13.4 we can't go and change the code generation and thus the code semantics (Dotty can and apparently does), but we can do the analysis with the assumption of idempotency. That's what this does: in MatchApproximator's TreeMakersToProps use a cache for the binders so when we see two extractions that are equivalent we reuse the same binder, so it translates into the same SAT variable.

view details

Dale Wijnand

commit sha 48ec4ced109063abc1051df22f2a9cdaba0b2562

Implement -Xnon-strict-patmat-analysis

view details

push time in 3 days

pull request commentscala/scala

optimise the iteration of a ListMap

The 2.12.x branch regularly gets merged into 2.13, with attempts to carry over as much as possible.

mkeskells

comment created time in 3 days

push eventdwijnand/scala

Dale Wijnand

commit sha acd8aa6bd4630f8558cca986f3fde3ec413b3bd5

Allow forks to run bootstrapped tests on Travis CI

view details

push time in 3 days

PullRequestReviewEvent

push eventdwijnand/scala

bjornregnell

commit sha 2b012729e963429823c095ae4890f2b1e83d5e0c

fix #11676 un-deprecate useful StringOps operations

view details

Kazuhiro Sera

commit sha 1aacda21e067e7a019798033b204c5db551836e7

Fix #12065 by adding scaladocs

view details

Kazuhiro Sera

commit sha fff2b81b0c7fc1ce3616ba4c3c2308008bfe5672

Update a comment as suggested

view details

M.Shibuya

commit sha 84aed73cf8413e4d2020e6e422b09721db4916c3

Fix ArrayBuffer incorrectly reporting the upper bound in IndexOutOfBoundsException Fixes scala/bug#12176

view details

Georgi Krastev

commit sha 31a3f9921fb9e12af2ca734dcd20cdcc9c9a8451

Use correct tree for child unapply context Prevents `ClassCastException` in some GADT scenarios and makes valid code compile in others. The parent context tree could be the case def itself. In that case creating a child context with the same tree breaks the logic to restore saved type bounds in `typedCase`, because `enclosingCaseDef` returns the child instead of the parent. This leads to saving modified bounds in the child context but later trying and failing to restore them in the parent context. The leaked bounds later cause type errors in the best case or propagate incorrect information to erasure in the worst case. Using the tree of the unapply itself for the child context means that `enclosingCaseDef` will return the parent context.

view details

Mitsuhiro Shibuya

commit sha d47ea5bf7097b8070070bd30e98dd2351cadaa72

Test remove(Int) and remove(Int, Int) separately as suggested here: https://github.com/scala/scala/pull/9249#discussion_r508456058 Co-authored-by: Diego E. Alonso Blas <diesalbla@gmail.com>

view details

Lukas Rytz

commit sha 9faf48bd7a0132cfa03761b1aef8fc3225cc04db

Merge pull request #9254 from joroKr21/gadt-cce Use correct tree for child unapply context

view details

Som Snytt

commit sha 8e2f16e0abff06b1115d31762a9e6cb242a30b5d

Java imports compete with level 4 definitions Like Scala, an import in Java can shadow a definition in another file, if it is not import-on-demand. The implementation bailed too quickly from searching enclosing contexts while testing this condition.

view details

Som Snytt

commit sha 2878d88fca23fe2cb4b255bf978b87dc7164c114

Additional regression test

view details

NthPortal

commit sha 1390315b03bb32ffdfb1394b3ec6f4619faca1b8

[bug#3088][bug#12121] Fix adding/subtracting ListBuffer to/from itself Fix appending a `ListBuffer` to itself and subtracting a `ListBuffer` from itself. Fix appending a `Growable` that uses the default `addAll` implementation to itself.

view details

NthPortal

commit sha 8f6e522778f23e5b9a51d0b938ed6d20ea0f0d85

[bug#12009] Make ListBuffer's iterator fail-fast Make `ListBuffer`'s iterator fail-fast when the buffer is mutated after the iterator's creation. Co-authored-by: Jason Zaugg <jzaugg@gmail.com>

view details

Som Snytt

commit sha 71bce77a19a994f37659d9d163b26a4c967e279f

Use unmixed backticks more uniformly

view details

Princess | April

commit sha 9a716985fcfbb687a3b4cfe97e8eb1d88a65057d

Merge pull request #9174 from NthPortal/topic/mutation-tracking-iterators/PR [bug#12009] Make ListBuffer's iterator fail-fast

view details

Lukas Rytz

commit sha 7f6b956e1a49910abe6f47c2e6d2c690a8a4bdbc

Merge pull request #9255 from som-snytt/issue/12195

view details

Dale Wijnand

commit sha d7edb38b398825abde3ee16ecb35be27a6c34a18

Merge pull request #9256 from som-snytt/tweak/old-quotes

view details

Dale Wijnand

commit sha 4b8eea0c95caaf7c23cc8534a21a990cb8029200

Merge pull request #9249 from mshibuya/issue/12176

view details

Dale Wijnand

commit sha 6e96b92df4741e27ce9483e250f588a771097d07

Merge pull request #9251 from seratch/issue-12065

view details

Dale Wijnand

commit sha 698fa731375364374924fe08bfd308cfec59d4f0

Merge pull request #9246 from bjornregnell/fix_undeprecate_useful_StringOps fixes scala/bug #11676 un-deprecate useful StringOps operations

view details

Dale Wijnand

commit sha f52d5e9fae1ebc75c4cdfe5a2b589391e894404e

Allow forks to run bootstrapped tests on Travis CI

view details

push time in 3 days

issue commentscala/bug

interaction at-a-distance for sam type and self type??

@dwijnand surely this is a bug, not an enhancement?

I've concluded that these matters are subjective. The closest I've found to a good way to discriminating is going off of what a specification says. But even then that's not good enough: see the blocking {} thing and the default execution context and how we're going to revert the change for 2.13.4...

Coming back to this, it was recorded as a feature in scala/scala-dev so I tried to preserve that by using scala/bug's enhancement. But personally I've given up on such labels (also why I sometimes refer to these as "tickets" rather than "issues").

adriaanm

comment created time in 3 days

pull request commentscala/scala

Upgrade to sbt 1.4.1

The diff is good, but to avoid mistakes I won't give it a green checkmark...

eatkins

comment created time in 3 days

pull request commentscala/scala

Upgrade to sbt 1.4.1

personally I'd be comfortable seeing this merged now, but perhaps Cautious Dale will want to wait until after 2.13.4 is released

Yeah, this doesn't affect the release and there isn't even a non-release reason for which this needs to be merged this week or next.

eatkins

comment created time in 3 days

Pull request review commentscala/scala

Upgrade to sbt 1.4.1

 lazy val commonSettings = instanceSettings ++ clearSourceAndResourceDirectories   Compile / unmanagedResourceDirectories += (ThisBuild / baseDirectory).value / "src" / thisProject.value.id,   sourcesInBase := false,   Compile / scalaSource := (Compile / sourceDirectory).value,-  Compile / javaSource := (Compile / sourceDirectory).value,-  // resources are stored along source files in our current layout-  Compile / resourceDirectory := (Compile / sourceDirectory).value,

Okie dokie, thank you!

eatkins

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentscala/bug

update double checked locking impl

Looking at https://github.com/scala/scala/commit/d9974be376e23f2a41373cd85977732aee6761a1 it looks almost like part of the impl was changed to follow shipilev's guidance while the other was left as a TODO?

adriaanm

comment created time in 3 days

issue commentscala/scala-dev

SI-8576 Vector should have SerialVersionUID, and other problems with SI-8549 discovered by the Xcheckinit build

Closing in favour of https://github.com/scala/bug/issues/8576.

szeiger

comment created time in 3 days

issue closedscala/scala-dev

Failure to compute LUBs for refined type

Welcome to Scala 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_91).

scala> trait M[+A]
defined trait M

scala> lub(typeOf[M[Int] with M[Any]] :: typeOf[M[String]] :: Nil)
res6: $r.intp.global.Type = Object

scala> lub(typeOf[M[Int] with M[Any]] :: typeOf[M[String] with M[Any]] :: Nil)
res7: $r.intp.global.Type = Object

I think this is because lubList::loop is unaware of the lazily computed base type elements of compound types (encoded as RefinedType(parents)).

        // Is the frontier made up of types with the same symbol?
        val isUniformFrontier = (ts0: @unchecked) match {
          case t :: ts  => ts forall (_.typeSymbol == t.typeSymbol)
        }

If we call BaseTypeSeq#typeSymbol at an index with such a type, we get the type symbol of the parents (they are always all the same). But the lub code effectively calls rawElem(i).typeSymbol. As such, it fails to recognize the uniform frontier, and rides north towards of to the horizon of Object.

closed time in 3 days

retronym

issue commentscala/scala-dev

Failure to compute LUBs for refined type

Looks fixed to me!

Welcome to Scala 2.13.3 (OpenJDK 64-Bit Server VM, Java 11.0.8).
Type in expressions for evaluation. Or try :help.
trait M[+A]

scala> trait M[+A]
trait M

scala> :power
Power mode enabled. :phase is at typer.
import scala.tools.nsc._, intp.global._, definitions._
Try :help or completions for vals._ and power._

scala> lub(typeOf[M[Int] with M[Any]] :: typeOf[M[String]] :: Nil)
val res0: $r.intp.global.Type = M[Any]

scala> lub(typeOf[M[Int] with M[Any]] :: typeOf[M[String] with M[Any]] :: Nil)
val res1: $r.intp.global.Type = M[Any]
retronym

comment created time in 3 days

issue closedscala/scala-dev

Bridge or omit troublesome additional abstract methods in specialized traits

Interaction with specialization

Specialization adds another small challenge. In the example below, notice how apply : (Int)V has been added to the specialized sub interface. A Java subclass of T$mcI$sp would need to implement both apply-s. T$mcI$sp is not a functional interface, so can't be used in LambdaMetafactory / (e.g. as the target type of a Java lambda expressions).

We run straight into this problem with the specialized Scala function traits.

% cat sandbox/spec.scala
trait T[@specialized A] {
  def t(a: A): Unit
}

% scalac sandbox/spec.scala && javap -classpath . T 'T$mcI$sp'
Compiled from "spec.scala"
public interface T{
    public abstract void t(java.lang.Object);
    public abstract void t$mcZ$sp(boolean);
    public abstract void t$mcB$sp(byte);
    public abstract void t$mcC$sp(char);
    public abstract void t$mcD$sp(double);
    public abstract void t$mcF$sp(float);
    public abstract void t$mcI$sp(int);
    public abstract void t$mcJ$sp(long);
    public abstract void t$mcS$sp(short);
    public abstract void t$mcV$sp(scala.runtime.BoxedUnit);
}

Compiled from "spec.scala"
public interface T$mcI$sp extends T{
    public abstract void t(int);
}

Contrast with a regular trait that inherits another trait:

cat sandbox/spec.scala && scalac sandbox/spec.scala && javap -classpath . U V
trait U[A] {
  def t(a: A): Unit
}
trait V extends U[Int]
Compiled from "spec.scala"
public interface U{
    public abstract void t(java.lang.Object);
}

Compiled from "spec.scala"
public interface V extends U{
}

We should investigate whether addition of this method by specialization is necessary / intentional. If we cannot omit it, we do have the possibility to bridge it.

public interface T$mcI$sp extends T{
    public abstract void t(int) = UNBOX(t$mcI$sp(BOX(arg)))
}

Scala callers never route into this method:

% cat sandbox/spec.scala && scalac sandbox/spec.scala && javap -c -classpath . Client
trait T[@specialized -A] {
  def t(a: A): Unit
}

class Client {
  def f(tint:  T[Int])= tint.t(0)
  def g[A](t: T[A], a: A) = t.t(a)
}
Compiled from "spec.scala"
public class Client extends java.lang.Object{
public void f(T);
  Code:
   0:   aload_1
   1:   iconst_0
   2:   invokeinterface #16,  2; //InterfaceMethod T.t$mcI$sp:(I)V
   7:   return

public void g(T, java.lang.Object);
  Code:
   0:   aload_1
   1:   aload_2
   2:   invokeinterface #26,  2; //InterfaceMethod T.t:(Ljava/lang/Object;)V
   7:   return

public Client();
  Code:
   0:   aload_0
   1:   invokespecial   #32; //Method java/lang/Object."<init>":()V
   4:   return

}

closed time in 3 days

retronym

issue commentscala/scala-dev

Bridge or omit troublesome additional abstract methods in specialized traits

Closing because it doesn't seem to have become an issue. But (@retronym) we can reopen and move it to scala/bug if need be.

retronym

comment created time in 3 days

issue closedscala/scala-dev

Java compiler crash with our library: undeclared type variable: B1

-> scala.collection.JavaConversions$.MODULE$.collectionAsScalaIterable(Exception in thread "main" com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file: /code/scala/build/quick/classes/library/scala/collection/immutable/HashMap$$anon$2$$anon$3.class
  undeclared type variable: B1
  Please remove or make sure it appears in the correct subdirectory of the classpath.
    at com.sun.tools.javac.jvm.ClassReader.badClassFile(ClassReader.java:266)
    at com.sun.tools.javac.jvm.ClassReader.findTypeVar(ClassReader.java:856)
    at com.sun.tools.javac.jvm.ClassReader.readEnclosingMethodAttr(ClassReader.java:1194)
    at com.sun.tools.javac.jvm.ClassReader$11.read(ClassReader.java:1037)
    at com.sun.tools.javac.jvm.ClassReader.readAttrs(ClassReader.java:1280)
    at com.sun.tools.javac.jvm.ClassReader.readClassAttrs(ClassReader.java:1295)
    at com.sun.tools.javac.jvm.ClassReader.readClass(ClassReader.java:2246)
    at com.sun.tools.javac.jvm.ClassReader.readClassBuffer(ClassReader.java:2344)
    at com.sun.tools.javac.jvm.ClassReader.readClassFile(ClassReader.java:2357)
    at com.sun.tools.javac.code.ClassFinder.fillIn(ClassFinder.java:350)
    at com.sun.tools.javac.code.ClassFinder.complete(ClassFinder.java:287)
    at com.sun.tools.javac.code.ClassFinder.access$000(ClassFinder.java:74)
    at com.sun.tools.javac.code.ClassFinder$1.complete(ClassFinder.java:166)
    at com.sun.tools.javac.code.Symbol.complete(Symbol.java:590)
    at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:1085)
    at com.sun.tools.javac.code.Symbol$ClassSymbol.flags(Symbol.java:1019)
    at com.sun.tools.javac.comp.Check.importAccessible(Check.java:3644)
    at com.sun.tools.javac.comp.TypeEnter$ImportsPhase.lambda$resolveImports$2(TypeEnter.java:330)
    at com.sun.tools.javac.code.Scope$FilterImportScope$SymbolImporter.lambda$importFrom$0(Scope.java:938)
    at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:176)
    at java.util.Spliterators$IteratorSpliterator.tryAdvance(Spliterators.java:1812)

closed time in 3 days

retronym

issue commentscala/scala-dev

Java compiler crash with our library: undeclared type variable: B1

Is that jshell? I can't reproduce it:

$ jshell --class-path $(cs fetch -p scala)
|  Welcome to JShell -- Version 11.0.8
|  For an introduction type: /help intro

jshell> scala.collection.JavaConversions$.MODULE$.collectionAsScalaIterable(
<press tab again to see all possible completions; total possible completions: 540>

jshell> scala.collection.JavaConversions$.MODULE$.collectionAsScalaIterable(
AbstractCollection                       AbstractExecutorService                  AbstractList                             AbstractMap                              AbstractMethodError
AbstractPreferences                      AbstractQueue                            AbstractSequentialList                   AbstractSet                              AccessDeniedException
...

... closing.

retronym

comment created time in 3 days

issue closedscala/scala-dev

Consider removal of `test/files/codelib/code.jar` and `test/files/speclib/instrumented.jar`

code.jar may not be necessary anymore. instrumented.jar could either be built by sbt on demand or the tests that use it (in specialized) ported to the new testing style in instrumented. Both JARs' locations are hardcoded in https://github.com/scala/scala-partest and partest will fail to run if they are missing, even if they are not required by the tests.

closed time in 3 days

szeiger

issue closedscala/scala-dev

Consider use x.getClass as a null check

These are semantically equivalent:

if (x eq null) throw new NullPointerException() //1
if (x eq null) throw null //2
x.getClass //3

We use option 2 in our null checks for the outer pointer in inner class constructors. I just noticed that javac used option 3 when spinning up a lambda based on an instance method reference.

    //  0: aload_0
    //  1: astore_1
    //  2: aload_1
    //  3: dup
    //  4: invokevirtual #3                  // Method java/lang/Object.getClass:()Ljava/lang/Class;
    //  7: pop
    //  8: invokedynamic #2,  0              // InvokeDynamic #0:x:(LTest;)LTest$FI1; (invokevirtual Test.bar:(Ljava/lang/Object;Ljava/lang/Object;)V)
    // 13: areturn
FI1 a1() { Test t1 = this; return t1::bar; }

closed time in 3 days

retronym

issue commentscala/scala-dev

Consider use x.getClass as a null check

Curious, but sounds like the status quo is good enough or better.

retronym

comment created time in 3 days

issue closedscala/scala-dev

Issues and Ideas for Scaladoc

Ideas / General Issues

  • [ ] When using multiple @see in docstrings, the order gets scrambled - should not happen. Same applies to @note
  • [ ] Search the text of the doc comments in addition to the method names (TBD, not sure if feasible performance-wise)
  • [ ] Make the EntityIterator in index.js switch between right and left by visibility instead of index
  • [ ] Async all the things!
    • Tried this naively on writeFor methods, no performance gain, need to profile - crashed
  • [ ] Auto-expand groups and hidden members on permalink or anchor click.
    • When a member is hidden by default, or by filter, and then selected via permalink or anchor click on page, the member must be shown to the user in the same manner as a visible member.
  • [x] Differentiate between object_class_comp.svg and object_trait_comp.svg (fixed in: https://github.com/scala/scala/pull/5077)
  • [x] When trying to expand the 'Full Signature' of a method that is shown as '[use case]', for example Option . max., the method body collapses (fixed in: https://github.com/scala/scala/pull/5077)
  • [x] scala.Predef is missing from sidebar when browsing other scala.X entities (might be all objects without companion class/trait) (fixed in: https://github.com/scala/scala/pull/5077)
  • [x] Predef extends ... needs to go away (sidebar)
  • [x] In search results, place spacer before (c) instead of after. Also place (o) before (c) or (t). This'll make the search uniform to the sidebar (http://imgur.com/a/c1uyX) (fixed in: https://github.com/scala/scala/pull/5077)
  • [x] Add type members to search in IndexScript.scala
  • [x] Be able to navigate back to search results from a clicked search result entity
  • [x] Fix regression where anchor-links don't highlight the target member
  • [x] Fix anchor links mentioned here: https://github.com/scala/scala/pull/5018#issuecomment-195020665
  • [x] Change behavior of "x"-button on input fields to only be removed if there is no input (changed from .on("blur", function () { ... }))
  • [x] Remove Template.scala and other unused files
  • [x] Remove dark bg on entity #definition
  • [x] Remove unfold arrows in favor of highlighted left side
  • [x] Unclutter contained classes (i.e. classes listed in package definition)
  • [x] Hover-text on packages
  • [x] Add sub-packages to side along with parent package of current entity for quick nav
  • [x] Useful search result hover text use first sentence until the next point is added (https://github.com/scala/scala/pull/4978)
  • [x] Add @shortDescription annotation for use with hover-text and short method summary StreamBuffer in Graphviz. Vlad says to instantiate a generator for each Graphviz
  • [x] add some indicator that search is in progress

Desktop issues

  • [ ] Can't use Page Up / Page Down because of input keybindings
  • [ ] Add @VladUreche's search from: https://github.com/scala/scala/pull/4912#issuecomment-183719491
  • [ ] Keyboard navigation for members
  • [x] Member indentation: https://github.com/scala/scala/pull/4912#issuecomment-183904610
    • Best bet is to refactor the docs to use a table element instead of an ordered list (solved by different behavior for mobile and desktop)
  • [x] Clicking on a package doesn't open its doc
  • [x] There's a triangle when on top of the modifiers when looking at the "Full Signature" (TraversableLike.foreach), see [3] https://github.com/scala/scala/pull/4912#issuecomment-184160480
  • [x] Enable member filtering for types https://github.com/scala/scala/pull/4972

Mobile Issues

General

  • [ ] When rotating the phone to landscape the font becomes quite large (compare [1] and [2]) see https://github.com/scala/scala/pull/4912#issuecomment-184160480
  • [ ] Unfolding the doc comment of TraversableOnce.reduceRight: the text is too large and overflow, not everything is readable
  • [x] Remove auto-capitalization in input field (by: @lrytz)
  • [x] There's no more get the abstract modifier (TraversableLike.foreach, package mutable) - is that by design?

Android

  • [x] On phones with large resolutions (1440x2560) method indentation is weird (should be fixed by https://github.com/scala/scala/pull/4912)
  • [x] when entering the search box, the version number shows up again. it disappears when leaving the search box (Chrome)

iOS

  • [ ] Unfolding / folding the doc of a member requires two taps. the first seems to do what hovering does on the desktop version.
  • [x] Down triangle is replaced by an emoji on iOS, use a glyph from the material icons font instead (already in scaladoc), when this is done - perhaps the layout of the member should be rethought to be more responsive
  • [x] Jumpy scroll sometimes, sometimes only header moves (Safari & Chrome)
  • [x] Some pages take a really long time to display - could be because of dropbox hosting (Chrome & Safari)
  • [x] When clicking on a member, the page sometimes jumps to the top (Chrome & Safari)
  • [x] Some page bodies are wider than the screen, for example "object Boolean" (@lrytz)

closed time in 3 days

felixmulder

issue commentscala/scala-dev

Issues and Ideas for Scaladoc

Closing as this is a big ticket, with lots of finished work in it. If any of the remaining points are especially significant, let's fork it off into a separate issue.

felixmulder

comment created time in 3 days

more