- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
STrange varargs issue
Sun, 2010-03-21, 18:32
All,
When I updated to the current nightly, I noticed the following odity:
def open : R
def close(r : R) : Unit
//Overridable list of exceptions we can partiall ignore.
protected def caughtException : Array[Class[_]] = Array(classOf[Throwable])
// Trouble Method
override def acquireFor[B](f : R => B) : Either[List[Throwable], B] = {
import scala.util.control.Exception._
val handle = open
val result = catching(caughtException : _*) either (f(handle)) // ***************** The problem line! *********************8
val close = catching(caughtException : _*) either unsafeClose(handle)
//Combine resulting exceptions as necessary
result.left.map[List[Throwable]]( _ :: close.left.toOption.toList)
}
Here's the issue I see at runtime:
java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to java.lang.Class
at scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Funny enough, Here's the byte code around that line:
20: invokeinterface #68, 1; //InterfaceMethod scala/resource/AbstractManagedResource.caughtException:()[Ljava/lang/Class;
25: checkcast #19; //class java/lang/Class
So... where is the erroneous checkcast coming in? I think somehow I'm performing some magic instance of steps that causes this. I'm trying to boil down into a minimal test-case, but so far those are all working, so I'm rather confused here. Anyone have any ideas on recent changes that could have caused this, or point me in the right direction of trying to fix it?
Thanks!
- Josh
When I updated to the current nightly, I noticed the following odity:
def open : R
def close(r : R) : Unit
//Overridable list of exceptions we can partiall ignore.
protected def caughtException : Array[Class[_]] = Array(classOf[Throwable])
// Trouble Method
override def acquireFor[B](f : R => B) : Either[List[Throwable], B] = {
import scala.util.control.Exception._
val handle = open
val result = catching(caughtException : _*) either (f(handle)) // ***************** The problem line! *********************8
val close = catching(caughtException : _*) either unsafeClose(handle)
//Combine resulting exceptions as necessary
result.left.map[List[Throwable]]( _ :: close.left.toOption.toList)
}
Here's the issue I see at runtime:
java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to java.lang.Class
at scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Funny enough, Here's the byte code around that line:
20: invokeinterface #68, 1; //InterfaceMethod scala/resource/AbstractManagedResource.caughtException:()[Ljava/lang/Class;
25: checkcast #19; //class java/lang/Class
So... where is the erroneous checkcast coming in? I think somehow I'm performing some magic instance of steps that causes this. I'm trying to boil down into a minimal test-case, but so far those are all working, so I'm rather confused here. Anyone have any ideas on recent changes that could have caused this, or point me in the right direction of trying to fix it?
Thanks!
- Josh
Sun, 2010-03-21, 19:27
#2
Re: STrange varargs issue
I can include more, but yes, as I stated, I couldn't reproduce without
the full source. I'll see if I can dig any further.
Sent from my iPhone
On Mar 21, 2010, at 2:13 PM, Paul Phillips wrote:
> On Sun, Mar 21, 2010 at 01:32:31PM -0400, Josh Suereth wrote:
>> Here's the issue I see at runtime:
>> java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to
>> java.lang.Class
>> at
>> scala.resource.AbstractManagedResource$class.acquireFor
>> (AbstractManagedResource.scala:71)
>
> Exception does some atypical things, so I would guess it's a
> component,
> but I couldn't reproduce it based on what you gave so I don't know.
> You
> omitted too much context, especially around the checkcast. I would
> guess it will end up being a corner case in the propagation of
> varargs:
> catching takes varargs, calls a function with the same varargs, and
> then
> that function calls another function passing the varargs value but not
> as varargs, as a Seq.
>
Mon, 2010-03-22, 01:07
#3
Re: STrange varargs issue
Turns out this is only an issue when one of your parent traits have continuation methods in them (with @cps). I'm going to try to reduce the test case, but I have a failing partest now that requries the continuations plugin on. I'm posting to trac, unless anyone has seen this before...
- Josh
On Sun, Mar 21, 2010 at 2:18 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
- Josh
On Sun, Mar 21, 2010 at 2:18 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I can include more, but yes, as I stated, I couldn't reproduce without the full source. I'll see if I can dig any further.
Sent from my iPhone
On Mar 21, 2010, at 2:13 PM, Paul Phillips <paulp@improving.org> wrote:
On Sun, Mar 21, 2010 at 01:32:31PM -0400, Josh Suereth wrote:
Here's the issue I see at runtime:
java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to
java.lang.Class
at
scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Exception does some atypical things, so I would guess it's a component,
but I couldn't reproduce it based on what you gave so I don't know. You
omitted too much context, especially around the checkcast. I would
guess it will end up being a corner case in the propagation of varargs:
catching takes varargs, calls a function with the same varargs, and then
that function calls another function passing the varargs value but not
as varargs, as a Seq.
Mon, 2010-03-22, 15:27
#4
Re: STrange varargs issue
http://lampsvn.epfl.ch/trac/scala/ticket/3199
In case anyone is intersted. As an aside: Should we enable the continuations plugin and re-run all the existing partest tests with the continuations plugin to ensure there are no side-effects?
On Sun, Mar 21, 2010 at 8:04 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
In case anyone is intersted. As an aside: Should we enable the continuations plugin and re-run all the existing partest tests with the continuations plugin to ensure there are no side-effects?
On Sun, Mar 21, 2010 at 8:04 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
Turns out this is only an issue when one of your parent traits have continuation methods in them (with @cps). I'm going to try to reduce the test case, but I have a failing partest now that requries the continuations plugin on. I'm posting to trac, unless anyone has seen this before...
- Josh
On Sun, Mar 21, 2010 at 2:18 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I can include more, but yes, as I stated, I couldn't reproduce without the full source. I'll see if I can dig any further.
Sent from my iPhone
On Mar 21, 2010, at 2:13 PM, Paul Phillips <paulp@improving.org> wrote:
On Sun, Mar 21, 2010 at 01:32:31PM -0400, Josh Suereth wrote:
Here's the issue I see at runtime:
java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to
java.lang.Class
at
scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Exception does some atypical things, so I would guess it's a component,
but I couldn't reproduce it based on what you gave so I don't know. You
omitted too much context, especially around the checkcast. I would
guess it will end up being a corner case in the propagation of varargs:
catching takes varargs, calls a function with the same varargs, and then
that function calls another function passing the varargs value but not
as varargs, as a Seq.
Mon, 2010-03-22, 16:07
#5
Re: STrange varargs issue
I'm working on it right know and I think I know what's going wrong. There is a check missing so vararg symbols get a wrong type and erasure later inserts the checkcast.
I ran partest with the plugin enabled and the error manifests itself in a number of other tests as well. I'm not sure what should be the default, though. Ideally we'd want to make sure everything works both with and without the plugin, but it's probably not practical to run the complete suite twice.
- Tiark
On Mar 22, 2010, at 3:18 PM, Josh Suereth wrote:
I ran partest with the plugin enabled and the error manifests itself in a number of other tests as well. I'm not sure what should be the default, though. Ideally we'd want to make sure everything works both with and without the plugin, but it's probably not practical to run the complete suite twice.
- Tiark
On Mar 22, 2010, at 3:18 PM, Josh Suereth wrote:
http://lampsvn.epfl.ch/trac/scala/ticket/3199
In case anyone is intersted. As an aside: Should we enable the continuations plugin and re-run all the existing partest tests with the continuations plugin to ensure there are no side-effects?
On Sun, Mar 21, 2010 at 8:04 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:Turns out this is only an issue when one of your parent traits have continuation methods in them (with @cps). I'm going to try to reduce the test case, but I have a failing partest now that requries the continuations plugin on. I'm posting to trac, unless anyone has seen this before...
- Josh
On Sun, Mar 21, 2010 at 2:18 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I can include more, but yes, as I stated, I couldn't reproduce without the full source. I'll see if I can dig any further.
Sent from my iPhone
On Mar 21, 2010, at 2:13 PM, Paul Phillips <paulp@improving.org> wrote:
On Sun, Mar 21, 2010 at 01:32:31PM -0400, Josh Suereth wrote:
Here's the issue I see at runtime:
java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to
java.lang.Class
at
scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Exception does some atypical things, so I would guess it's a component,
but I couldn't reproduce it based on what you gave so I don't know. You
omitted too much context, especially around the checkcast. I would
guess it will end up being a corner case in the propagation of varargs:
catching takes varargs, calls a function with the same varargs, and then
that function calls another function passing the varargs value but not
as varargs, as a Seq.
Mon, 2010-03-22, 16:17
#6
Re: STrange varargs issue
I think having an ant task to call that would run both twice would be ideal. This could run in the hudson nightly at least to ensure that minor changes to the compiler to not inadvertently break the plugin. At least if the plugin is intended to be distributed with the scala distribution.
- Josh
On Mon, Mar 22, 2010 at 11:06 AM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:
- Josh
On Mon, Mar 22, 2010 at 11:06 AM, Tiark Rompf <tiark.rompf@epfl.ch> wrote:
I'm working on it right know and I think I know what's going wrong. There is a check missing so vararg symbols get a wrong type and erasure later inserts the checkcast.
I ran partest with the plugin enabled and the error manifests itself in a number of other tests as well. I'm not sure what should be the default, though. Ideally we'd want to make sure everything works both with and without the plugin, but it's probably not practical to run the complete suite twice.
- Tiark
On Mar 22, 2010, at 3:18 PM, Josh Suereth wrote:http://lampsvn.epfl.ch/trac/scala/ticket/3199
In case anyone is intersted. As an aside: Should we enable the continuations plugin and re-run all the existing partest tests with the continuations plugin to ensure there are no side-effects?
On Sun, Mar 21, 2010 at 8:04 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:Turns out this is only an issue when one of your parent traits have continuation methods in them (with @cps). I'm going to try to reduce the test case, but I have a failing partest now that requries the continuations plugin on. I'm posting to trac, unless anyone has seen this before...
- Josh
On Sun, Mar 21, 2010 at 2:18 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I can include more, but yes, as I stated, I couldn't reproduce without the full source. I'll see if I can dig any further.
Sent from my iPhone
On Mar 21, 2010, at 2:13 PM, Paul Phillips <paulp@improving.org> wrote:
On Sun, Mar 21, 2010 at 01:32:31PM -0400, Josh Suereth wrote:
Here's the issue I see at runtime:
java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to
java.lang.Class
at
scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Exception does some atypical things, so I would guess it's a component,
but I couldn't reproduce it based on what you gave so I don't know. You
omitted too much context, especially around the checkcast. I would
guess it will end up being a corner case in the propagation of varargs:
catching takes varargs, calls a function with the same varargs, and then
that function calls another function passing the varargs value but not
as varargs, as a Seq.
On Sun, Mar 21, 2010 at 01:32:31PM -0400, Josh Suereth wrote:
> Here's the issue I see at runtime:
> java.lang.ClassCastException: [Ljava.lang.Class; cannot be cast to
> java.lang.Class
> at
> scala.resource.AbstractManagedResource$class.acquireFor(AbstractManagedResource.scala:71)
Exception does some atypical things, so I would guess it's a component,
but I couldn't reproduce it based on what you gave so I don't know. You
omitted too much context, especially around the checkcast. I would
guess it will end up being a corner case in the propagation of varargs:
catching takes varargs, calls a function with the same varargs, and then
that function calls another function passing the varargs value but not
as varargs, as a Seq.