Merge 2.12.x to 2.13.x [ci: last-only] #8993
Conversation
backport 2.13 immutable RedBlackTree to 2.12
…mark_backport backport a benchmark. Adjust API for 2.12
Avoid creation of Option for TreeMap.getOrElse
avoid creation of ListBuffers for Seq.empty and Seq()
remove stale mima exception
use seq to work correctly with parallel collections
Dehoist many closures from Types
better diagnostics from AllocationTest
While profiling a build I noticed that calls to disectApplied via `isSelfOrSuperConstrCall` was an allocation hotspot. These use cases only need to strip Apply/TypeApply, so in this commit I've duplicated a few lines of code to to this.
- Avoid null checks by comparing Symbols with eq rather than ==
- Eagerly compute `selectorClass` to avoid null check on each
access, and pass it as a parameter rather than as a field.
…ructuctorCall Avoid allocation of TreeInfo.Applied
Microopts in FindMember
No Unit.depends bookkeeping if -Ytrack-dependencies:false
Direct implementations of MapN.{filterImpl,exists,forall}
(cherry picked from commit 8821b30)
Optimized iterators for immutable.SetN
Avoids projecting to a temporary List.
(cherry picked from commit 3e223d1)
Optimized filter for immutable.SetN
Avoids creating iterators and using builders and reuses the
input collection when the predicate selects all elements.
(cherry picked from commit 20b4596)
Improve performance of atPos under -Yrangepos
Put @transient on an (inner) object and it works kinda like @transient lazy val, as you may have expected.
Last time I tried this I got called out for relaxing too much. As justification, Java does not respect self types (so there would be a separate-compilation inconsistency to try to enforce them) nor does it understand non-stable prefixes. Fixes scala/bug#11917, or at least kinda patches over it.
Makes scala faster to build and to download; what's not to like?
Reduce the size of WrappedArray
… collection.immutable.Seq#canBuildFrom Update List#flatMap to - share the last list non-empty segment if we can easily - reduce allocations in other cases - improve CPU usage add test for isLikeListReusableCBF to ensure that if a future Scala version change to result of the Seq builder we detect the change and can adjust accordingly
|
Backport of the backend changes to defensively avoid witnessing uninitialised or stale maxlocals: #8997 |
|
Tests are green now, the |
Erroneous commit was: ``` commit 2c620a7 Merge: abcde58 8270221 Author: Jason Zaugg <[email protected]> Date: Thu May 14 11:17:30 2020 +1000 Merge commit '8270221567' into merge/2.12.x-to-2.13.x-20200514 ``` According to scala#8783, which removed `|| k != tree.key`, there was no behaviour change in 2.13.x, this was just a cleanup.
lrytz
force-pushed
the
merge/2.12.x-to-2.13.x-20200514
branch
2 times, most recently
from
99039c1 to
69ff105
Compare
|
I looked at the read sites of However, I agree that it's brittle, and I agree that new helper methods to access the maxs is a better way forward. I'll do that. |
lrytz
force-pushed
the
merge/2.12.x-to-2.13.x-20200514
branch
from
69ff105 to
6d1cdae
Compare
|
That cleanup LVGTM, @lrytz |
|
/nothingtoseehere |
Discussed at team meeting today. Our sense is that this package of changes seems safe enough (and anyway, the 2.13.2 regressions are not so many or so severe that 2.13.3 needs to be ultra-conservative). |
|
labeled with "release-notes" since it seems likely that 2.13.3 will come out before 2.12.12 does, so we might need 2.13.3 release-notes for some of these 2.12.x changes |
|
Is there a list of 2.13.2 regressions somewhere? |
|
I found them by looking at the issues with milestone 2.13.3 and the regressions label: https://github.com/scala/bug/issues?q=milestone%3A2.13.3+ |
…3.x-20200514 Merge 2.12.x to 2.13.x [ci: last-only]
…3.x-20200514 Merge 2.12.x to 2.13.x [ci: last-only]
Tricky parts:
an uninitialized or stale MethodNode.maxLocals, typically when the read
occured before a preceding lazy val had been initialized:
lazy val a = new AsmAnalyzer(m); m.maxLocalsforward ported, but I have brought relevant test cases forward.
Only the final commit of this branch is expected to pass the tests.
We need to decide if this should all come forward to 2.13.x immediately, or
whether to defer anything until post 2.13.3. I can prepare a new PR with a
squashed subset of this branch.