-
Notifications
You must be signed in to change notification settings - Fork 92
2.13: compatibility with new name-based extractor scheme #253
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
Comments
(sorting this out is a blocker for releasing 2.13.0-M5) |
Right, if the community build is using the newCollectionsBootstrap branch from #222, then it should be compiling still for 2.13.0-M4. We hardcoded Is there a test somewhere in the compiler to verify pattern matching with |
I think the part of scala/scala#7068 that's causing the problem is "This PR changes the type of |
I'll try this in the community build: scalacommunitybuild/scala-xml@5f67a6f |
Here are the definitions of Elem.unapplySeq(n: Node): Option[(String, String, MetaData, NamespaceBinding, Seq[Node])]
Node.unapplySeq(n: Node): Some[(String, MetaData, Seq[Node])]
QNode.unapplySeq(n: Node): Some[(String, String, MetaData, Seq[Node])] And adding |
Guess we'll see! |
as far as I can see that would cross-compile, yes. but, perhaps there's a more efficient solution if we're concerned about avoiding unnecessary copying? would need a little thought/investigation |
I've tried to write a minimal partest that replicates the import scala.collection.AbstractSeq
import scala.collection.SeqOps
import scala.collection.immutable.StrictOptimizedSeqOps
abstract class CollectionSeq
extends AbstractSeq[Int]
with scala.collection.Seq[Int]
with SeqOps[Int, scala.collection.immutable.Seq, CollectionSeq]
with StrictOptimizedSeqOps[Int, scala.collection.immutable.Seq, CollectionSeq]
{
def first: Int
def more: scala.collection.Seq[CollectionSeq]
def iterator: Iterator[Int] = ???
def apply(i: Int): Int = ???
def length: Int = ???
}
case class CollSeqCons(first: Int, more: CollectionSeq*) extends CollectionSeq
object CollectionSeq {
def unapplySeq(x: CollectionSeq) = Some((x.first, x.more))
}
object Test extends App {
def f(x: CollectionSeq): CollectionSeq = x match {
case CollSeqCons(x, xs @ _*) => CollSeqCons(x, xs: _*)
}
} |
attn @lrytz |
I looked into this issue, I didn't see anything unexpected. We should improve the error message though for RC1, as the change breaks existing Here's a self-contained reproduction: abstract class Node extends NodeSeq {
def label: String
def child: scala.collection.Seq[Node]
}
object Elem {
def unapplySeq(n: Node): Option[(String, collection.Seq[Node])] = Some((n.label, n.child))
}
abstract class NodeSeq extends collection.immutable.Seq[Node] {
def theSeq: collection.Seq[Node]
def length = theSeq.length
def iterator = theSeq.iterator
def apply(i: Int): Node = theSeq(i)
}
object NodeSeq {
import scala.language.implicitConversions
implicit def seqToNodeSeq(s: collection.Seq[Node]): NodeSeq = new NodeSeq {
def theSeq = s
}
}
object Test {
def foo(n: Node) = n match {
case Elem(label, child @ _*) => child
}
} The error message is because the binding
This fails to type-check and produces the error message ( Note that it's enough to change |
Did adding I tried compiling on the latest M5 with Seth's branch:
When I look in the last passing 2.13 community build from Aug-22 I only see scala-xml getting skipped:
Hopefully, I'm using the right M5:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I believe this got fixed in 2.13.0-M5 by scala/scala#7120. I'm having a hard time remembering. |
after scala/scala#7068 was merged, in the 2.13 community build (https://scala-ci.typesafe.com/job/scala-2.13.x-integrate-community-build/1371/consoleFull) we have:
and a few more such errors.
does this indicate that there is code in scala-xml that needs to be adjusted to the new scheme for name-based extractors? or is there a flaw in scala/scala#7068?
The text was updated successfully, but these errors were encountered: