Scala 2.11.3 is on Maven Central (not an announcement)

[Grzegorz Kossakowski]

Hi,

Scala 2.11.3 is on Maven Central already. Official announcement will follow in a few days once I wrap up a few things related to release notes.

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Takashi Kawachi]

Hi,

I just want to notify SI-8899. Scala 2.11.3 has a binary compatibility issue. Play, Akka, Scalaz and Scalatra are known to be broken. Please have a look at https://issues.scala-lang.org/browse/SI-8899.

Thanks,

2014年10月11日土曜日 23時48分18秒 UTC+9 Grzegorz Kossakowski:

[Grzegorz Kossakowski]

Hi Takashi!

Thanks for the timely report!

We're looking into this report and also https://issues.scala-lang.org/browse/SI-8900. Both of them look like blockers.

More details to follow once we have a chance to look a bit deeper and understand what happened.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Miles Sabin]

FYI, a shapeless user has been able to reproduce a Scala 2.11.2/3,
shapeless 2.0.0 binary compatibility problem here,

https://github.com/ahjohannessen/shapeless-scala-bug

Cheers,


Miles

Miles Sabin
tel: +44 7813 944 528
skype: milessabin
gtalk: mi...@milessabin.com
g+: http://www.milessabin.com
http://twitter.com/milessabin

[Eugene Burmako]

Interesting. Shapeless's POM [1] says that scala-reflect is provided, but something in its API [2] actually requires scala-reflect to be available on compilation classpath. You're saying this was working in 2.11.2?

[1] https://oss.sonatype.org/content/repositories/releases/com/chuusai/shapeless_2.11/2.0.0/shapeless_2.11-2.0.0.pom

[2] https://github.com/milessabin/shapeless/blob/master/core/src/main/scala/shapeless/poly.scala

[Lukas Rytz]

If you check out the above repo and set scalaVersion to 2.11.2 it compiles.

I could not manage to reproduce the failure without using sbt, not sure where to look right now.

[Miles Sabin]

On Mon, Oct 13, 2014 at 2:44 PM, Eugene Burmako <eugene....@epfl.ch> wrote:
> Interesting. Shapeless's POM [1] says that scala-reflect is provided, but
> something in its API [2] actually requires scala-reflect to be available on
> compilation classpath. You're saying this was working in 2.11.2?

This was definitely working with 2.11.2.

Cheers,


Miles

[Antoine Gourlay]

On Mon, Oct 13, 2014 at 3:46 PM, Lukas Rytz <lukas...@gmail.com> wrote:

If you check out the above repo and set scalaVersion to 2.11.2 it compiles.

I could not manage to reproduce the failure without using sbt, not sure where to look right now.

Running a quick git bisect with jenkins’ pack.tgz says this regressed in 0ccdb15, but from there I have no idea…

​

[Lukas Rytz]

Thanks, Antoine

--

[Jason Zaugg]

In both 2.11.2 and 2.11.3, the Unpickler creates stub symbols for references of shapless.PolyDefns to symbols in scala-reflect.jar if it is not present on the classpath.

The change to isStaticModule in 0ccdb15 more aggressively executes info transformers on classfile based symbols.

Here’s a minimization and an exploration of how to make our stub symbols even stubbier.

Not sure it that’s a good idea or not yet. An alternative might be to change isModuleNotMethod to be more selective about when forcing the info makes sense, or perhaps catching the MissingRequirementError and demoting it to a dev warning if the symbol isn’t part of this compilation run. Lukas, WDYT?

    def isModuleNotMethod = {
      if (isModule) {
        if (phase.refChecked) this.info // force completion to make sure lateMETHOD is there.
        !isMethod
      } else false
    }

The problem didn’t show up under the command line scalac, as that always adds scala-reflect.jar to the classpath.

-jason

​

[Lukas Rytz]

Why doesn't sbt add scala-reflect.jar to the classpath, if shapeless.jar depends on it? Is that common,

or is it something special about scala-reflect?

I have the feeling that the compiler is implemented with the assumption of finding all necesssary

dependencies on the classpath, and other problems would pop up after working around this one.

(It seems we have to do an exception for annotations: SI-5420 / SI-7551/ SI-7751)

[Jason Zaugg]

On Tue, Oct 14, 2014 at 3:53 PM, Lukas Rytz <lukas...@gmail.com> wrote:

Why doesn't sbt add scala-reflect.jar to the classpath, if shapeless.jar depends on it? Is that common,

or is it something special about scala-reflect?

Dependencies in the `provided` scope are intransitive.

% git grep '"provided'
project/Build.scala:            "org.scala-lang" % "scala-reflect" % sv % "provided",

​

 

I have the feeling that the compiler is implemented with the assumption of finding all necesssary

dependencies on the classpath, and other problems would pop up after working around this one.

(It seems we have to do an exception for annotations: SI-5420 / SI-7551/ SI-7751)

StubSymbols are for more than just annotations. For example, you should not need a classpath to support the signatures of methods you don’t use in a class.

% cat sandbox/stub1.scala && qscalac sandbox/stub1.scala && rm C.class && qscala -e "def test(d: D) = d.zzz"
class C

class D {
  def ccc(c: C) = c

  def zzz = "z"
}

javac behaves in this manner, too.

We have no need to elaborate the type signature of PolyDefns.Case.materializeFromValueImpl, we should tread more lightly. In this failing test, we get there in a pretty circuitous manner, so it isn't immediately obvious where to remedy this.

​

-jason

[Lukas Rytz]

OK, thanks for more details. I fear that we could get unexpected / wrong results when

taking stub symbols too far, because they often give you an answer and don't crash:

scala> val stub = new global.StubTermSymbol(NoSymbol, "hai", "msg")

stub: $r.global.StubTermSymbol = value hai

scala> stub.isMethod

res4: Boolean = false

scala> stub.isClass

res5: Boolean = false

scala> stub.isModule

res6: Boolean = false

(btw, how do you get these nice monospace boxes in gmail?)

So maybe it's better to avoid creating even more?

[Jason Zaugg]

On Tue, Oct 14, 2014 at 4:39 PM, Lukas Rytz <lukas...@gmail.com> wrote:

OK, thanks for more details. I fear that we could get unexpected / wrong results when

taking stub symbols too far, because they often give you an answer and don't crash:

scala> val stub = new global.StubTermSymbol(NoSymbol, "hai", "msg")

stub: $r.global.StubTermSymbol = value hai

scala> stub.isMethod

res4: Boolean = false

scala> stub.isClass

res5: Boolean = false

scala> stub.isModule

res6: Boolean = false

(btw, how do you get these nice monospace boxes in gmail?)

I'm using the Markdown Here extension for Chrome. For some reason github style syntax highlighting has stopped working for me, but it is supposed to support that too.

So maybe it's better to avoid creating even more?

If you ever call .info on them they will fail. It is a fine balance, but I can’t really think of an alternative design. It might be interesting to take a look at javac’s implementation of these.

I think we can fix this particular bug by making isModuleNotMethod only force as far as it needs to get the lateMETHOD flag installed (ie, to refchecks). I’ll submit a patch and test for this, under the banner of SI-8907.

​

-jason

[Miles Sabin]

On 14 Oct 2014 07:08, "Jason Zaugg" <jza...@gmail.com> wrote:
>
> On Tue, Oct 14, 2014 at 3:53 PM, Lukas Rytz <lukas...@gmail.com> wrote:
>>
>> Why doesn't sbt add scala-reflect.jar to the classpath, if shapeless.jar depends on it? Is that common,
>> or is it something special about scala-reflect?
>
>
> Dependencies in the `provided` scope are intransitive.
>
> % git grep '"provided'
> project/Build.scala:            "org.scala-lang" % "scala-reflect" % sv % "provided",

Are you suggesting that I should drop the provided scope, either temporarily or permanently?

Cheers,

Miles

>
> ​
>  
>>
>> I have the feeling that the compiler is implemented with the assumption of finding all necesssary
>> dependencies on the classpath, and other problems would pop up after working around this one.
>>
>> (It seems we have to do an exception for annotations: SI-5420 / SI-7551/ SI-7751)
>>
> StubSymbols are for more than just annotations. For example, you should not need a classpath to support the signatures of methods you don’t use in a class.
>
> % cat sandbox/stub1.scala && qscalac sandbox/stub1.scala && rm C.class && qscala -e "def test(d: D) = d.zzz"
> class C
>
> class D {
>   def ccc(c: C) = c
>
>   def zzz = "z"
> }
>
> javac behaves in this manner, too.
>
> We have no need to elaborate the type signature of PolyDefns.Case.materializeFromValueImpl, we should tread more lightly. In this failing test, we get there in a pretty circuitous manner, so it isn't immediately obvious where to remedy this.
>
> ​
> -jason
>

[Jason Zaugg]

That won't be necessary with 2.10.4.

Jason

[Antoine Gourlay]

On Tue, Oct 14, 2014 at 12:22 PM, Jason Zaugg <jza...@gmail.com> wrote:

That won't be necessary with 2.10.4.

s/2.10.4/2.11.4/g ?

[Jason Zaugg]

Yep. I keep doing that, must be feeling nostalgic this week. 

--