multiple PRs are green on Jenkins, red on Travis-CI #570
Comments
|
Lukas thought at least one of the PRs might be stack size related, not sure what his evidence is probably no harm in just adding an
|
|
scala/scala#7368 was a transient failure due to a failed fetch of a binary artefact from a Lightbend repo ... went green on Travis when rerun. |
|
One step forward, one step back ... scala/scala#7199 is now failing with a SOE on Travis, after rebasing. In this case at least, the failure is after bootstrapping. |
|
Pattern matching is now generating additional null checks. I'm guessing this is an intended consequence of moving it after refchecks. These extra null checks are doubling the tree depth of the translated patterns, which was already pretty big for some of the high-arity tuple matches in I'll dig further.
|
|
Okay, that change comes down to a slightly older, intentional change to null handling with extractors: scala/scala#6485 Maybe we should change patmat to emit: Rather than: if (p5.ne(null)) { <next pattern> } else case12()WIP: https://github.com/scala/scala/compare/2.13.x...retronym:topic/shallower-patmat-ast?expand=1 |
|
The Scala.js backend won't be happy at all if you do that. It's very sensitive to the shapes of trees produced by the pattern matcher. The function |
|
Thanks for the heads up, @sjrd. We'll be make sure to allow time for that re-write, or otherwise, we can make the status quo available under a migration option of some sort. |
As identified in scala/scala-dev#570, pattern matching with extractors on long sequence patterns can lead to deep ASTs which require cranking up `-Xss` to get them through scalac. We can/should modify the pattern matcher to emit more shallow ASTs. My WIP for that is: https://github.com/scala/scala/compare/2.13.x...retronym:topic/shallower-patmat-ast?expand=1 But in the meantime, this PR refactors the TupleN unlifters in the quasiquotes implementation to share the logic in a loop based implementation.
As identified in scala/scala-dev#570, pattern matching with extractors on long sequence patterns can lead to deep ASTs which require cranking up `-Xss` to get them through scalac. We can/should modify the pattern matcher to emit more shallow ASTs. My WIP for that is: https://github.com/scala/scala/compare/2.13.x...retronym:topic/shallower-patmat-ast?expand=1 But in the meantime, this PR refactors the TupleN unlifters in the quasiquotes implementation to share the logic in a loop based implementation. These code paths are covered by the exiting test: > scalacheck/testOnly scala.reflect.quasiquotes.UnliftableProps
As identified in scala/scala-dev#570, pattern matching with extractors on long sequence patterns can lead to deep ASTs which require cranking up `-Xss` to get them through scalac. We can/should modify the pattern matcher to emit more shallow ASTs. My WIP for that is: https://github.com/scala/scala/compare/2.13.x...retronym:topic/shallower-patmat-ast?expand=1 But in the meantime, this PR refactors the TupleN unlifters in the quasiquotes implementation to share the logic in a loop based implementation. These code paths are covered by the exiting test: > scalacheck/testOnly scala.reflect.quasiquotes.UnliftableProps
As identified in scala/scala-dev#570, pattern matching with extractors on long sequence patterns can lead to deep ASTs which require cranking up `-Xss` to get them through scalac. We can/should modify the pattern matcher to emit more shallow ASTs. My WIP for that is: https://github.com/scala/scala/compare/2.13.x...retronym:topic/shallower-patmat-ast?expand=1 But in the meantime, this PR refactors the TupleN unlifters in the quasiquotes implementation to share the logic in a loop based implementation. These code paths are covered by the exiting test: > scalacheck/testOnly scala.reflect.quasiquotes.UnliftableProps
We've seen stack overflows on travis lately. Since we're using 1m on Jenkins and didn't see failures, let's see if Xss1m fixes it on travis scala/scala-dev#570
We've seen stack overflows on travis lately. Since we're using 1m on Jenkins and didn't see failures, let's see if Xss1m fixes it on travis scala/scala-dev#570
We've seen stack overflows on travis lately. Since we're using 1M on Jenkins and didn't see failures, let's see if Xss1M fixes it on travis. scala/scala-dev#570
We've seen stack overflows on travis lately. Since we're using 1M on Jenkins and didn't see failures, let's see if Xss1M fixes it on travis. scala/scala-dev#570
|
Just saw the SOE on the most recent merge commit in 2.13.x, which includes the |
|
gah, not sure what to do here, earliest I could look at it or think about it is next week |
|
Is there any reason for not being a bit more generous with heap and stack? I use 3g and 2m respectively for shapeless. |
|
I guess we'd like to understand why this started happening recently and keep some pressure to do something about it. But the cost of having spurious failures over and over again is probably a bit too high. So I'm happy to bump to 2m. |
|
SGTM. we could leave this ticket open unless or until we decide do something else |
|
Want to try scala/scala#7375 first? |
|
I don't recall seeing this happen recently |
(list has been edited based on comments below)
By-name implicits: Align detection of implicit recursion with the SIP scala#7368never mindThe text was updated successfully, but these errors were encountered: