the 2.10.1-RC1 sprint

[Adriaan Moors]

Hi,

Please reduce the number of bugs assigned to you and marked as fix-by 2.10.1-RC1 to no more than 12, or whatever you feel comfortable fixing in time for 2.10.1-RC1 (Feb 11), as this is a mere dozen working days away. Very few mortals manage to fix more than a bug a day on average in scalac and friends.

Bugs that don't make the cut should be (multiple answers possible):

• be bumped to 2.10.2-RC1
• be bumped to 2.11.0-M2
• unassigned

Current rankings can be seen here:

https://issues.scala-lang.org/browse/SI/fixforversion/11314

thanks!

adriaan

ps: yes, i also still need to go through this exercise

[Szabolcs Berecz]

Hi,

I need some help determining the time frame for the two issues that are assigned to me:
https://issues.scala-lang.org/browse/SI-6289 (blocker, fix version: 2.10.1-RC1)
https://issues.scala-lang.org/browse/SI-7003 (no fix version)

I don't consider SI-6289 to be blocker and a proper fix needs SI-7003 to be fixed first. I also think that SI-7003 is more important, so that's what I'm working on. I'm positive that I can fix the latter til Feb 11, but not SI-6289.

So, that would mean bumping SI-6289 to 2.10.2-RC1 while reducing it's severity, and setting fix version 2.10.1-RC1 for SI-7003. Do you agree?

If SI-6289 is really that important, then somebody should take it from me.

[Adriaan Moors]

Thanks for looking into this!

I agree it shouldn't block the release, but I'd still consider eliminating silent killers like this a priority.

If you have any questions we can help with on the mailing list, we'll do our best to help out.

I left the priority at major, but tentatively set the fix-by version to 2.10.1. As they're not blockers, worst case they'll slip to the next release.

thanks!

adriaan

[Paul Phillips]

It makes me ill to see anyone working on partest. I don't suppose you'd like to look into this instead:

  https://github.com/paulp/scala/tree/topic/partest-sprint

I can't swear that particular partest rewrite is among the ones in which I have fixed the javac error output retention, but I know I've fixed it somewhere. [Time passes] Now I can swear it. I added a test.

  https://github.com/paulp/scala/blob/topic/partest-sprint/test/files/neg/javac-error.check

Look, pretty colors.

[Szabolcs Berecz]

On Thu, Jan 24, 2013 at 3:25 PM, Paul Phillips <pa...@improving.org> wrote:

It makes me ill to see anyone working on partest. I don't suppose you'd like to look into this instead:

  https://github.com/paulp/scala/tree/topic/partest-sprint

I can't swear that particular partest rewrite is among the ones in which I have fixed the javac error output retention, but I know I've fixed it somewhere. [Time passes] Now I can swear it. I added a test.

I'm curious, does it also pass on Java 7? :) What's the saying about that? I mean, java 6 and 7 have somewhat different console output which can be rectified by filtering but it's gonna be fragile (javax.tools doesn't help). AFAIK not every test passes on java 7, so I guess it's "try to make it work but don't sweat it if it brakes later"?

Anyway, I'll take a look and try to integrate into master/2.10.x, but first I want to make sure that all output is checked (SI-7003).
 

  https://github.com/paulp/scala/blob/topic/partest-sprint/tehttp://vastagbor.blog.hu/2013/01/24/az_alfold_legnagyobb_szankodombjast/files/neg/javac-error.check

Look, pretty colors.

--
 
 

[Paul Phillips]

On Thu, Jan 24, 2013 at 6:59 AM, Szabolcs Berecz <szabolc...@gmail.com> wrote:

I'm curious, does it also pass on Java 7? :) What's the saying about that? I mean, java 6 and 7 have somewhat different console output which can be rectified by filtering but it's gonna be fragile (javax.tools doesn't help). AFAIK not every test passes on java 7, so I guess it's "try to make it work but don't sweat it if it brakes later"?

Actually all the tests do pass on java7 right now (not that they all are likely to pass on this 5-month-old branch) and that tells you how well we're testing javac. It's one or the other of 6 or 7 as things are right now; checkfiles which vary by java version awaits its doer.

The colorized word diff tell us the addition of the word "error" is the difference from 6 to 7.

[Adriaan Moors]

It makes me giddy to see these pretty screenshots. Soooo pretty. 

--
 
 

[Som Snytt]

At the risk of turning Paul's stomach, I'll try to sprint the last leg of the relay.

I would scarf my old "fastest" branch and Paul's pretty branch.

The feature set includes a slightly faster test run (a couple of minutes last summer, IIRC), saving artifacts to disk only on test failure, preserving output on grouped compiles, and of course any/all goodies from partest-sprint.  Though sometimes colorization makes me nauseous.

As a feature bonus, I'll try versioned checkfiles.  I've encountered that a bit because javap output is different for java 6 and 7.

On Thu, Jan 24, 2013 at 6:59 AM, Szabolcs Berecz <szabolc...@gmail.com> wrote:

  https://github.com/paulp/scala/blob/topic/partest-sprint/tehttp://vastagbor.blog.hu/2013/01/24/az_alfold_legnagyobb_szankodombjast/files/neg/javac-error.check

Look, pretty colors.

--
 
 

--
 
 

[Paul Phillips]

On Thu, Jan 24, 2013 at 10:03 AM, Som Snytt <som....@gmail.com> wrote:

At the risk of turning Paul's stomach, I'll try to sprint the last leg of the relay.

It issued barely a rumble.

If you're able to merge that branch into master and see things working again (it makes me cry, how much time goes to the merge demon) I can throw my shoulder behind it once more and hopefully we can overcome whatever obstacles remain.

 

Though sometimes colorization makes me nauseous.

For the peanut gallery, let me emphasize I have not yet tuned the colors. Unlike my behavior in most domains, I am tasteful and reserved when it comes to colorizing console output.

 

As a feature bonus, I'll try versioned checkfiles.  I've encountered that a bit because javap output is different for java 6 and 7.

Given how long this partest situation has dragged on, if you have energy for the last mile, I beg you to conserve it. Versioned checkfiles will still be there.

[Jason Zaugg]

On Thu, Jan 24, 2013 at 7:03 PM, Som Snytt <som....@gmail.com> wrote:

At the risk of turning Paul's stomach, I'll try to sprint the last leg of the relay.

I would scarf my old "fastest" branch and Paul's pretty branch.

The feature set includes a slightly faster test run (a couple of minutes last summer, IIRC), saving artifacts to disk only on test failure, preserving output on grouped compiles, and of course any/all goodies from partest-sprint.  Though sometimes colorization makes me nauseous.

As a feature bonus, I'll try versioned checkfiles.  I've encountered that a bit because javap output is different for java 6 and 7.

Bytecode verification of all generated classes would be neat, too. Perhaps behind a flag if it's too much of a performance drag for a non CI build. (I've been getting towards the finish line for SI-6666, and the new checks pointed out that the fix for SI-6259 generates invalid bytecode.) scala.tools.asm.util.CheckClassAdapter is ready and willing to assist in this challenge.

-jason

[James Iry]

At one point Paul hacked an extension to -Xverify that used CheckClassAdapter to do a byte code verify, but I don't know what happened to the hack.

On Jan 24, 2013, at 11:10 AM, Jason Zaugg <jza...@gmail.com> wrote:

>
> Bytecode verification of all generated classes would be neat, too. Perhaps behind a flag if it's too much of a performance drag for a non CI build. (I've been getting towards the finish line for SI-6666, and the new checks pointed out that the fix for SI-6259 generates invalid bytecode.) scala.tools.asm.util.CheckClassAdapter is ready and willing to assist in this challenge.
>
> -jason
>

> --
>
>

[Paul Phillips]

On Thu, Jan 24, 2013 at 11:17 AM, James Iry <jame...@typesafe.com> wrote:

At one point Paul hacked an extension to -Xverify that used CheckClassAdapter to do a byte code verify, but I don't know what happened to the hack.

Aagh, it's getting bloody over here with the corpses of things undone.

  https://github.com/paulp/scala/tree/pr/asm-verify

I stalled on finishing it because it isn't only a matter of throwing individual classes at it - you need a whole internally consistent world, and (for example) there are pos tests which involve java source code, generate scala bytecode, and then fail verification because there is no java bytecode.

[Adriaan Moors]

It makes me giddy to see these pretty screenshots. Soooo pretty. 

On Thursday, January 24, 2013, Paul Phillips wrote:

--
 
 

[Jason Zaugg]

Yeah, that's a bit prickly.

I tried that patch, on this code that had my head scratching today.

  https://gist.github.com/4628662

Interestingly enough, just by loading the class, in:

    private def loads(name: String) = 

       try   { Class.forName(name, true, this) ; true }

       catch { case ex: LinkageError => false }

 

the VerifyError isn't triggered; only by changing the second parameter, 'initialize', to true, does the problem reveal itself. Obviously not something you can switch on in general.

The JVM spec states:

"This specification allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that all of the following properties are maintained:

• A class or interface is completely loaded before it is linked.

• A class or interface is completely verified and prepared before it is initialized.

• Errors detected during linkage are thrown at a point in the program where some action is taken by the program that might, directly or indirectly, require linkage to the class or interface involved in the error."

The ASMVerifier doesn't offer any more details. I ran the BCEL verifer, which does pinpoints the problem.

Instruction INVOKESPECIAL constraint violated: Expecting a 'Test$InVal$2$' but found a '<UNINITIALIZED OBJECT OF TYPE 'Test$InVal$2$'>' on the stack (which is not assignment compatible).

The closure sprouts an $outer pointer when defined in the RHS of the local val definition, which means we pass the poisonous, unitialized `this` reference out too early.

My patch for SI-6666 detects and prevents when that happens and issues an implementation restriction, but I now see i need to investigate whether we can uniformly avoid the outer pointer.

-jason

[Jonas Bonér]

On Thu, Jan 24, 2013 at 6:08 PM, Adriaan Moors <adriaa...@typesafe.com> wrote:

It makes me giddy to see these pretty screenshots. Soooo pretty. 

Yeah, I found myself drooling. 

 

--
 
 

--
Jonas Bonér
Phone: +46 733 777 123
Home: http://jonasboner.com
Twitter: @jboner