Scala-dev: Release 2.11.10

[adriaanm]

Scala 2.11.9 (see #330) contained a critical regression in binary stability (due to scala/scala#5664), which is why we are reverting the binary incompatible commits of that PR in scala/scala#5821 and releasing 2.11.10 (this week) without announcing 2.11.9.

Additionally, #352 is fixed by scala/scala#5828 (thanks @xuwei-k and @sjrd).

These are the only changes with respect to 2.11.9

[adriaanm]

https://scala-ci.typesafe.com/job/scala-2.11.x-integrate-bootstrap/906/:

• scala/scala@d9150aaec8431f79b426761826ce44ac3a61a92b
• Closed sonatype staging repos:
  
  
  
  • https://oss.sonatype.org/content/repositories/orgscala-lang-1398
  
  
  • https://oss.sonatype.org/content/repositories/orgscala-lang-1399
  
  

https://scala-ci.typesafe.com/job/scala-2.11.x-release-package-unix/801/:

• scala/scala-dist@01285f0475fec7a21bb4cb1f30363df2e294966d

[adriaanm]

Bytecode diff due diligence

Compiling the 2.11.10 code base with 2.11.8 and itself yields the following diff in javap -vp output: https://gist.github.com/adriaanm/da437b85be0c5e3c6dc0269443a4e63f. Two differences:

• catchExpr$1 due to https://github.com/scala/scala/commit/3f3a3bb57499fb919e798d03bbc4e84ede8e55d6
• two vararg bridges lose their ACC_SYNTHETIC -- https://github.com/scala/scala/pull/5631/commits/a75d3fdda25f228779ba7a6345571e6fce941197

Sadly, there was no additional diff between 2.11.8 and 2.11.9, so I'm not sure how much this tells us.

[xeno-by]

@adriaanm Paradise 2.11.10 works: https://github.com/scalamacros/paradise/commit/3bc2bd227ce6759178d18213e4382019a64d8f1c.

[adriaanm]

I also checked the full bytecode of the 2.11.8/10 libraries compiled with their respective compiler: https://gist.github.com/adriaanm/c72ae563f7784a15e1ea75799b2daae9

I think 2.11.10 is ready to go.

[adriaanm]

Tags pushed and staging repo promoted. Will publish release notes and announce next week

[xeno-by]

Paradise 2.1.0 for Scala 2.11.10 has just been released: https://oss.sonatype.org/content/repositories/releases/org/scalamacros/paradise_2.11.10/2.1.0/.

[sjrd]

Scala.js 0.6.15 for Scala 2.11.10 has been released too.

[xeno-by]

Pre-release builds of meta 1.7.0 and meta paradise 3.0.0-M8 have been built against 2.11.10 without problems.

[adriaanm]

Well, my embarrassment just went up another notch. The 2.12 community build found another issue with my apply/unapply fix. (Point well taken, universe, point well taken.)

I should probably backport my 2.12 fix for https://github.com/scala/bug/issues/10261 to 2.11.x and release 2.11.11 once we're sure the 2.12 community build is all good. I really feel bad for wasting everyone's time and burning a few version numbers in the process, but it's probably the right thing to do.

What do you think?

[hepin1989]

I suggest take a little longer time and exhaustive test to make sure/wait it matured.
No one never done all goods:)

[sjrd]

What about reverting those changes altogether? I mean, it's basically a language change, that shouldn't be sneakily done in the last minor version of 2.11.x. Maybe that's the point the universe is trying to make? ;)

[som-snytt]

It's pretty cool that 2.11 will now go all the way to eleven.

[densh]

I second @sjrd's concern. Can we still revert this altogether in 2.11.x ?

[adriaanm]

I understand your concern, but we'd really like this change to be in both 2.11 and 2.12. It's a common (enough) pattern, and is currently compiled in a surprising (silently) wrong way.

Here's one example of where the framework's validation in the apply method won't be called if you use a case class: https://github.com/akka/akka-http/blob/master/akka-http-core/src/main/scala/akka/http/scaladsl/model/headers/headers.scala#L90-L109

[adriaanm]

I would agree it's a language implementation change, but not a language change. The code in Namers always had a comment that said an apply/unapply wouldn't be added if it would cause a conflict (like the copy method, where this logic was implemented). That logic was not implemented, so the compiler would crash if there was a conflict due to different levels of accessibility (or, silently emit the overriding synthetic method instead of favoring the existing one).

Now -- modulo my mistakes that should hopefully be fixed -- it is implemented, and I'd say it matches programmer intuition.

[adriaanm]

As a compromise, here's a PR that backports the latest issue revealed by the community build, and also puts the whole change under -Xsource:2.12: https://github.com/scala/scala/pull/5846

[adriaanm]

It's pretty cool that 2.11 will now go all the way to eleven.

And we have a title for the release notes :-)