-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rename ImmutableArray to ArraySeq #6611
Conversation
(this also needs a rebase on the partest in-source) |
I think we may need another collection - a |
a5ef951
to
52d755a
Compare
rebased on the insource-partest pr for now to test, but unfortunately that created 100 jobs on jenkins, as there's no |
Tests look good, but the |
Added another commit that renames |
Also, if we name it The change of semantics is also there in current 2.13.x, |
d7260f8
to
708551f
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@deprecated("Use WrappedArray instead of ArraySeq; it can represent both, boxed and unboxed arrays", "2.13.0") | ||
type ArraySeq[X] = WrappedArray[X] | ||
@deprecated("Use WrappedArray instead of ArraySeq; it can represent both, boxed and unboxed arrays", "2.13.0") | ||
val ArraySeq = WrappedArray.untagged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need the deprecated aliases in the other direction, if we're doing this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks for pointing that out. Though I think we should drop the second commit, keep mutable.WrappedArray
. Waiting for opinions on that still :-)
6da383c
to
39bb80c
Compare
Gah, this also needs a new scalacheck release.. I can do that through a There's also a binary incompatibility in the new macroAnnots tests.
@adriaanm are there any pre-compiled binaries involved here? Otherwise it must be that code is being compiled with the starr compiler, but then executed with locker or quick. Just running |
It turns out just rebuilding scalacheck with a local Scala version is not enough, because the scalacheck artifact depends on the Scala library it was built with. So that Scala version needs to be on maven... We can either
I vote for 2. |
👍 to in-sourcing |
39bb80c
to
e1dcb16
Compare
Added a commit that in-sources scalacheck. TODO: update IntelliJ templates. |
7ed3f52
to
b83a39a
Compare
0251064
to
e60f3e0
Compare
e60f3e0
to
e5a25cc
Compare
// !!! the null check should to be necessary, but without it 2241 fails. Seems to be a bug | ||
// in pattern matcher. @PP: I noted in #4364 I think the behavior is correct. | ||
// Is ImmutableArray safe here? In 2.12 we used to call .toIndexedSeq which copied the array | ||
// instead of wrapping it in a WrappedArray but it appears unnecessary. | ||
// Is ArraySeq safe here? In 2.12 we used to call .toIndexedSeq which copied the array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out it is not. We need to make a defensive copy. Varargs use immutable.Seq
so we can't just return a mutable.ArraySeq
but the Seq can leak out of a pattern match.
FYI, it turns out Scala.js also depends on this PR to be merged, if it does and what portions of it do :-s I had not realized that before. I've already updated after #6620. |
Sources from lrytz/scalacheck@1fd5eef
We get some linkage errors now. sbt seems to compile the compiler interface against the current version, which is 2.13.0-pre-SNAPSHOT, so something arbitrary. The scalaInstance in the macroAnnot project is the quick instance. That's probably the cause. We should convert macroAnnot tests to partest, where we do this bootstrap.
e5a25cc
to
ec070b7
Compare
I'll merge this as soon as it goes green. |
Fixes scala/bug#10836