(in)stability

Oh, and that was misleadingly (at best) phrased: what I was trying to
say is that the distribution is built with -optimise, not that it builds
other things with -optimise without being so commanded.

On Sat, Jan 23, 2010 at 10:33 PM, Paul Phillips wrote:
> Somehow my latest checkin r20640 has a stability failure on a single
> file:
>
> test.stability:
>     [same] File
> ' lasses/compiler/scala/tools/nsc/interpreter/StaticCompletion.class'> is
> different from correspondant.
>
> ...but the commit doesn't touch anything to do with code generation or
> the like, so I think it is revealing a pre-existing bug.
>
Yes, that could well be. Stability can be violated for a number of
reasons. Most common cause is that some table somewhere is just a
HashMap and not a LinkedHashMap. The best thing to do would be to find
out what changes and where. I.e compile -Xprint:clean outputs from
quick and strap and then do the same for the scalap disassemblies.
That could narrow it down.

Cheers

On Sun, Jan 24, 2010 at 11:27 AM, martin odersky wrote:
> On Sat, Jan 23, 2010 at 10:33 PM, Paul Phillips wrote:
>> Somehow my latest checkin r20640 has a stability failure on a single
>> file:
>>
>> test.stability:
>>     [same] File
>> '> lasses/compiler/scala/tools/nsc/interpreter/StaticCompletion.class'> is
>> different from correspondant.
>>
>> ...but the commit doesn't touch anything to do with code generation or
>> the like, so I think it is revealing a pre-existing bug.
>>
> Yes, that could well be. Stability can be violated for a number of
> reasons. Most common cause is that some table somewhere is just a
> HashMap and not a LinkedHashMap. The best thing to do would be to find
> out what changes and where. I.e compile -Xprint:clean outputs from
> quick and strap and then do the same for the scalap disassemblies.
> That could narrow it down.
>
Btw, if we do not get this solved right away the best option could be
to turn off the stability test for the builds until we know what the
problem is.

Cheers

The difference is in the ScalaSignature, probably some type is pickled
differently.

iulian

On Sun, Jan 24, 2010 at 11:40 AM, martin odersky wrote:
> On Sun, Jan 24, 2010 at 11:27 AM, martin odersky wrote:
>> On Sat, Jan 23, 2010 at 10:33 PM, Paul Phillips wrote:
>>> Somehow my latest checkin r20640 has a stability failure on a single
>>> file:
>>>
>>> test.stability:
>>>     [same] File
>>> '>> lasses/compiler/scala/tools/nsc/interpreter/StaticCompletion.class'> is
>>> different from correspondant.
>>>
>>> ...but the commit doesn't touch anything to do with code generation or
>>> the like, so I think it is revealing a pre-existing bug.
>>>
>> Yes, that could well be. Stability can be violated for a number of
>> reasons. Most common cause is that some table somewhere is just a
>> HashMap and not a LinkedHashMap. The best thing to do would be to find
>> out what changes and where. I.e compile -Xprint:clean outputs from
>> quick and strap and then do the same for the scalap disassemblies.
>> That could narrow it down.
>>
> Btw, if we do not get this solved right away the best option could be
> to turn off the stability test for the builds until we know what the
> problem is.
>
> Cheers
>
>  -- Martin
>

OK, I found what the problem is: The

lazy val clazz = ...

gets a complicated inferred type Class[$1 >: X with Y] where X and Y
are themselves existential type variables with lower bounds.
The order of X and Y is different in the two runs. I have not yet
found out why, and help in doing this would be appreciated. There's a
lot of code potentially involved, but one probably should start in
existentialAbstraction. In the meantime, it would be prudent to give
explicit type annotations for things that have existential types. The
other reason why this is good is that inferred existential types can
be quite complicated so type error messages involving them would be
large and confusing.

For the moment, I fixed the problem by adding the type annotation:

lazy val clazz: Class[_] = ...

You can reproduce the problem by compiling StaticCompletion with quick
and strap, after you have removed the annotation of clazz and after
you have uncommented the line that mentions StaticCompletion in
Pickler.scala. That will show you what gets pickled.

Cheers

Shoot, I was too slow. I just went through the exact same process and
was checking in the same patch when I saw yours come through. I got
sidetracked making tab-completion work on my ScalaSig objects so I can
examine them that way.

I have meant to bring up for a while that I have a lot of issues anytime
I deal with multiple java class objects. If I don't sprinkle around the
Class[_] ascriptions pretty aggressively, I tend to run into crashes or
type mismatches I don't want. I've never been able to usefully
propagate the constraints that appear on Class anyway, and it makes me
curious if anyone else has.

Example, and I don't know if the comment is still true, but in the repl
code there is:

// XXX if wrapperExceptions isn't type-annotated we crash scalac
val wrapperExceptions: List[Class[_ <: Throwable]] =
List(classOf[InvocationTargetException], classOf[ExceptionInInitializerError])