Ideas / General Issues

commit sha 7620439ecb6abef86de920c461d5b367a86e8b27

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

Disable fatal warnings in the library

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

1 commit in scala-steward/migration-manager/tree/update/coursier-2.0.5 lightbend/mima/tree/master

0 comment

1 changed file

scala-steward

pr closed time in 2 days

pull request commentscala/scala

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

commit sha 3b5c12d366e6c7083e6d6c8d18f6ac09a44f5c66

Allow forks to run bootstrapped tests on Travis CI

Clean up warnings in reflect module

push time in 2 days

pull request commentscala/scala

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

commit sha 18778ecfe11b3a485c0ed6e68ba74618638cb88f

Fix run/t12182, avoid exhaustivity warnings

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.

Greg Pfeil

commit sha c02a234cc9b0ac8e80d6d45537cbcddb04f14e36

Exhaustivity with extractors and unsealed traits.

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.

commit sha e8734c1a652557b2c98483c67da28a333d159bc7

Avoid exhaustive warnings in try/catch

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.

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).

commit sha c54081e75015c4490ade0787ebe45936731e2747

Always check exhaustivity of custom extractors/guards

commit sha 9519ebe36dc68e31bf28e775c15be9554175f6f4

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

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.

commit sha 0416c57a01a2b0feafc340893d64cd54ca7ae84c

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

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.

commit sha ac2c3c87b67f29175ff9655cdcfcb30eca96a6a4

Implement -Xnon-strict-patmat-analysis

commit sha 3808a6ac5d3d16d0bcb37f9bb9bd623ca364fc52

Mention reachability warnings on `@unchecked`

commit sha 1ac95fd9b1d1ad93e03148df2a48da0e544151e7

Merge pull request #9140 from dwijnand/exhaust

unapplySeq silences all exhaustivity warnings

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:

guards no longer disable exhaustivity checking (fixing scala/bug#5365)
refutable custom extractors also no longer disable exhaustivity checking
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:

dropping the final if g3; or
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

13 commit in dwijnand/scala/tree/exhaust scala/scala/tree/2.13.x

27 comments

191 changed files

dwijnand

pr closed time in 2 days

issue closedscala/bug

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

push eventNthPortal/scala

bjornregnell

commit sha 2b012729e963429823c095ae4890f2b1e83d5e0c

fix #11676 un-deprecate useful StringOps operations

commit sha 1aacda21e067e7a019798033b204c5db551836e7

Fix #12065 by adding scaladocs

zerosum

commit sha 6112b18d27a595eca0b39e5bbbaa7f308a01aa95

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

zerosum

commit sha f4e25d0313330f4772816d31e1453f65a8489fca

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

commit sha 57ae2a6cc6505d3b66be93a47b2cee938cce1aa3

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

commit sha fff2b81b0c7fc1ce3616ba4c3c2308008bfe5672

Update a comment as suggested

M.Shibuya

commit sha 84aed73cf8413e4d2020e6e422b09721db4916c3

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

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.

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>

commit sha 9faf48bd7a0132cfa03761b1aef8fc3225cc04db

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

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.

commit sha 2878d88fca23fe2cb4b255bf978b87dc7164c114

Additional regression test

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.

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>

commit sha 71bce77a19a994f37659d9d163b26a4c967e279f

Use unmixed backticks more uniformly

Princess | April

commit sha 9a716985fcfbb687a3b4cfe97e8eb1d88a65057d

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

commit sha 7f6b956e1a49910abe6f47c2e6d2c690a8a4bdbc

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

commit sha d7edb38b398825abde3ee16ecb35be27a6c34a18

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

commit sha 4b8eea0c95caaf7c23cc8534a21a990cb8029200

Merge pull request #9249 from mshibuya/issue/12176

commit sha 6e96b92df4741e27ce9483e250f588a771097d07

Merge pull request #9251 from seratch/issue-12065

push time in 2 days

push eventscala/scala

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.

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.

commit sha d3085491c726d9aa0142e63418876aa019644d69

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

commit sha 9d6a2ebb1a7d453acf9c6b63623386e3cb630964

Enable -Werror for reflect build

commit sha 239bf73fdfb5d659d181f2e25f9879aab49f62e3

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

commit sha 991ff8aa74cb5d7754420b9f381a9a242c3279f7

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

Register allocation on local variable slots

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

5 commit in NthPortal/scala/tree/topic/reflect-werror/PR scala/scala/tree/2.13.x

0 comment

38 changed files

NthPortal

pr closed time in 2 days

issue closedscala/bug

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

commit sha ac2c3c87b67f29175ff9655cdcfcb30eca96a6a4

Implement -Xnon-strict-patmat-analysis

commit sha 3808a6ac5d3d16d0bcb37f9bb9bd623ca364fc52

Mention reachability warnings on `@unchecked`

Introduces ExecutionContext.batchingGlobal and reverts ExecutionConte…

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

1 commit in viktorklang/scala/tree/wip-batching-global-√ scala/scala/tree/2.13.x

3 comments

2 changed files

viktorklang

pr closed time in 3 days

pull request commentscala/scala

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

1 commit in dwijnand/scala/tree/revert-batching-global scala/scala/tree/2.13.x

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

commit sha 6062d3ccbf22cb8c321601d8082face30bfa91f6

Mention reachability warnings on `@unchecked`

push time in 3 days

delete branch dwijnand/scala

delete branch : library-disable-fatal-warnings

delete time in 3 days

push eventscala/scala

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).

commit sha 59c6eda13ce3e72b4d687658ef1ff7b5f0e1e44c

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

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

1 commit in dwijnand/scala/tree/library-disable-fatal-warnings scala/scala/tree/2.13.x

0 comment

1 changed file

dwijnand

pr closed time in 3 days

push eventNthPortal/scala

commit sha 03437561922874e3d247aaff6ef54a00e8cfcd02

Enable -Werror for compiler build

commit sha b04ea78a24632c44b675858da62fb97364f980ed

Un-deprecate some shadowing inner classes in compiler

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.

push time in 3 days

push eventNthPortal/scala

commit sha c5ac0faac934c0195b74e6dc4fd25612b507fca8

Avoid deprecated any2stringadd in RefChecks

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.

push time in 3 days

push eventNthPortal/scala

commit sha 239bf73fdfb5d659d181f2e25f9879aab49f62e3

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

Clean up warnings in compiler module

push time in 3 days

PullRequestReviewEvent

pull request commentscala/scala

[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

commit sha 1cc0a05e396150b32cf8a968e6822b5c937fe9ca

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

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

1 commit in SethTisue/scala/tree/readme-nightlies scala/scala/tree/2.13.x

0 comment

1 changed file

SethTisue

pr closed time in 3 days

push eventdwijnand/scala

commit sha 4d6bddcc78d87dcf1362cab13a65a736eb58b213

Allow forks to run bootstrapped tests on Travis CI

branch : library-disable-fatal-warnings

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

1 commit in dwijnand/scala/tree/library-disable-fatal-warnings scala/scala/tree/2.13.x

0 comment

1 changed file

pr created time in 3 days

create barnchdwijnand/scala

created branch time in 3 days

push eventlightbend/mima

Scala Steward

commit sha 28fbe0ac6ffaac9abed8d8d5afa0c6d546afa146

Update typesafe:config to 1.4.1

commit sha a619b31ca25027a7b6bf4dc4d0e0688bcd9ec2dc

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

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

1 commit in scala-steward/migration-manager/tree/update/typesafe-1.4.1 lightbend/mima/tree/master

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

1 commit in dwijnand/scala/tree/build/allow-forks scala/scala/tree/2.13.x

0 comment

4 changed files

pr created time in 3 days

push eventdwijnand/scala

commit sha 0416c57a01a2b0feafc340893d64cd54ca7ae84c

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

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.

commit sha 48ec4ced109063abc1051df22f2a9cdaba0b2562

Implement -Xnon-strict-patmat-analysis

optimise the iteration of a ListMap

push time in 3 days

pull request commentscala/scala

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

commit sha acd8aa6bd4630f8558cca986f3fde3ec413b3bd5

Allow forks to run bootstrapped tests on Travis CI

push time in 3 days

PullRequestReviewEvent

push eventdwijnand/scala

bjornregnell

commit sha 2b012729e963429823c095ae4890f2b1e83d5e0c

fix #11676 un-deprecate useful StringOps operations

commit sha 1aacda21e067e7a019798033b204c5db551836e7

Fix #12065 by adding scaladocs

commit sha fff2b81b0c7fc1ce3616ba4c3c2308008bfe5672

Update a comment as suggested

M.Shibuya

commit sha 84aed73cf8413e4d2020e6e422b09721db4916c3

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

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.

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>

commit sha 9faf48bd7a0132cfa03761b1aef8fc3225cc04db

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

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.

commit sha 2878d88fca23fe2cb4b255bf978b87dc7164c114

Additional regression test

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.

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>

commit sha 71bce77a19a994f37659d9d163b26a4c967e279f

Use unmixed backticks more uniformly

Princess | April

commit sha 9a716985fcfbb687a3b4cfe97e8eb1d88a65057d

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

commit sha 7f6b956e1a49910abe6f47c2e6d2c690a8a4bdbc

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

commit sha d7edb38b398825abde3ee16ecb35be27a6c34a18

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

commit sha 4b8eea0c95caaf7c23cc8534a21a990cb8029200

Merge pull request #9249 from mshibuya/issue/12176

commit sha 6e96b92df4741e27ce9483e250f588a771097d07

Merge pull request #9251 from seratch/issue-12065

commit sha 698fa731375364374924fe08bfd308cfec59d4f0

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

commit sha f52d5e9fae1ebc75c4cdfe5a2b589391e894404e

Allow forks to run bootstrapped tests on Travis CI