Compiler Bug?

Hi!

I was just playing around, trying to get a better idea of higher kinded
types, so this probably doesn't make much sense:

class DependentMap[K[_]] private (map:Map[Any,Any] = Map[Any,Any]()) {
def +[V](k:K[V], v:V) = new DependentMap(map + (k -> v))
}

However, it also seems to break the compiler (this is Scala 2.8, I just
updated to the last Netbeans-Plugin), see the stacktrace below.

Cheers,
Daniel

java.lang.AssertionError: assertion failed
at scala.Predef$.assert(Predef.scala:92)
at
scala.tools.nsc.typechecker.Infer$Inferencer.qualify$1(Infer.scala:1026)
at
scala.tools.nsc.typechecker.Infer$Inferencer$$anonfun$checkKindBounds$1$$anonfun$apply$8.apply(Infer.scala:1042)
at
scala.tools.nsc.typechecker.Infer$Inferencer$$anonfun$checkKindBounds$1$$anonfun$apply$8.apply(Infer.scala:1041)
at
scala.collection.generic.TraversableTemplate$$anonfun$map$1.apply(TraversableTemplate.scala:178)
at
scala.collection.generic.TraversableTemplate$$anonfun$map$1.apply(TraversableTemplate.scala:178)
at
scala.collection.generic.LinearSequenceTemplate$class.foreach(LinearSequenceTemplate.scala:82)
at scala.collection.immutable.List.foreach(List.scala:26)
at
scala.collection.generic.TraversableTemplate$class.map(TraversableTemplate.scala:178)
at scala.collection.immutable.List.map(List.scala:26)
at
scala.tools.nsc.typechecker.Infer$Inferencer$$anonfun$checkKindBounds$1.apply(Infer.scala:1041)
at
scala.tools.nsc.typechecker.Infer$Inferencer$$anonfun$checkKindBounds$1.apply(Infer.scala:1034)
at
scala.collection.generic.LinearSequenceTemplate$class.foreach(LinearSequenceTemplate.scala:82)
at scala.collection.immutable.List.foreach(List.scala:26)
at
scala.tools.nsc.typechecker.Infer$Inferencer.checkKindBounds(Infer.scala:1034)
at
scala.tools.nsc.typechecker.Infer$Inferencer.checkBounds(Infer.scala:928)
at
scala.tools.nsc.typechecker.Infer$Inferencer.inferMethodInstance(Infer.scala:1147)
at
scala.tools.nsc.typechecker.Typers$Typer.doTypedApply(Typers.scala:2144)
at
scala.tools.nsc.typechecker.Typers$Typer.typedApply$1(Typers.scala:3058)
at
scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3648)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3755)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3808)
at
scala.tools.nsc.typechecker.Typers$Typer.computeType(Typers.scala:3859)
at
scala.tools.nsc.typechecker.Namers$Namer.methodSig(Namers.scala:1022)
at
scala.tools.nsc.typechecker.Namers$Namer.typeSig(Namers.scala:1119)
at
scala.tools.nsc.typechecker.Namers$Namer$$anonfun$typeCompleter$1.apply(Namers.scala:506)
at
scala.tools.nsc.typechecker.Namers$Namer$$anonfun$typeCompleter$1.apply(Namers.scala:504)
at
scala.tools.nsc.typechecker.Namers$$anon$1.complete(Namers.scala:1277)
at
scala.tools.nsc.typechecker.Namers$PolyTypeCompleter.complete(Namers.scala:1288)
at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:712)
at
scala.tools.nsc.symtab.Symbols$Symbol.initialize(Symbols.scala:821)
at
scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3469)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3755)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3797)
at
scala.tools.nsc.typechecker.Typers$Typer.typedStat$1(Typers.scala:1771)
at
scala.tools.nsc.typechecker.Typers$Typer$$anonfun$21.apply(Typers.scala:1828)
at
scala.tools.nsc.typechecker.Typers$Typer$$anonfun$21.apply(Typers.scala:1828)
at scala.collection.immutable.List$.loop$4(List.scala:712)
at scala.collection.immutable.List$.mapConserve(List.scala:729)
at scala.collection.immutable.List$.loop$4(List.scala:716)
at scala.collection.immutable.List$.mapConserve(List.scala:729)
at scala.collection.immutable.List$.loop$4(List.scala:716)
at scala.collection.immutable.List$.mapConserve(List.scala:729)
at
scala.tools.nsc.typechecker.Typers$Typer.typedStats(Typers.scala:1828)
at
scala.tools.nsc.typechecker.Typers$Typer.typedTemplate(Typers.scala:1347)
at
scala.tools.nsc.typechecker.Typers$Typer.typedClassDef(Typers.scala:1200)
at
scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3480)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3755)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3797)
at
scala.tools.nsc.typechecker.Typers$Typer.typedStat$1(Typers.scala:1771)
at
scala.tools.nsc.typechecker.Typers$Typer$$anonfun$21.apply(Typers.scala:1828)
at
scala.tools.nsc.typechecker.Typers$Typer$$anonfun$21.apply(Typers.scala:1828)
at scala.collection.immutable.List$.loop$4(List.scala:712)
at scala.collection.immutable.List$.mapConserve(List.scala:729)
at
scala.tools.nsc.typechecker.Typers$Typer.typedStats(Typers.scala:1828)
at
scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3476)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3755)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3797)
at
scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$2.apply(Analyzer.scala:57)
at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:311)
at
scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$2$$anonfun$run$1.apply(Analyzer.scala:51)
at
scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$2$$anonfun$run$1.apply(Analyzer.scala:51)
at scala.collection.Iterator$class.foreach(Iterator.scala:500)
at
scala.collection.mutable.ListBuffer$$anon$1.foreach(ListBuffer.scala:280)
at
scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$2.run(Analyzer.scala:51)
at scala.tools.nsc.Global$Run.compileSources(Global.scala:787)
at scala.tools.nsc.Global$Run.compile(Global.scala:861)
at
scala.tools.nsc.StandardCompileServer.session(CompileServer.scala:117)
at
scala.tools.util.SocketServer$$anonfun$run$1.apply(SocketServer.scala:81)
at
scala.tools.util.SocketServer$$anonfun$run$1.apply(SocketServer.scala:81)
at scala.util.DynamicVariable.withValue(DynamicVariable.scala:73)
at scala.Console$.withOut(Console.scala:84)
at scala.Console$.withOut(Console.scala:102)
at scala.tools.util.SocketServer.run(SocketServer.scala:80)
at
scala.tools.nsc.StandardCompileServer.main(CompileServer.scala:155)
at scala.tools.nsc.CompileServer.main(CompileServer.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
scala.util.ScalaClassLoader$$anonfun$run$1.apply(ClassLoader.scala:54)
at scala.util.ScalaClassLoader$class.asContext(ClassLoader.scala:21)
at scala.util.URLClassLoader.asContext(ClassLoader.scala:58)
at scala.util.ScalaClassLoader$class.run(ClassLoader.scala:54)
at scala.util.URLClassLoader.run(ClassLoader.scala:58)
at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:33)
at
scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:138)
at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
error: fatal error (server aborted): assertion failed
one error found
exception when typing new DependentMap(map.$plus(k.$minus$greater(v))), pt =
?
exception when typing def +[V >: _root_.scala.Nothing <:
_root_.scala.Any](k: K[V], v: V) = new
DependentMap(map.$plus(k.$minus$greater(v))), pt = ?
exception when typing class DependentMap[K[_ >: Nothing <: Any] >:
[_]Nothing <: [_]Any] extends scala.ScalaObject {
private[this] val map: Map[Any,Any] = _;
private def this(map: Map[Any, Any] = Map[Any, Any]()):
dependentMap.DependentMap[K] = {
DependentMap.super.this();
()
};
def +[V >: _root_.scala.Nothing <: _root_.scala.Any](k: K[V], v: V) = new
DependentMap(map.$plus(k.$minus$greater(v)))
}, pt = ?
exception when typing package dependentMap {
class DependentMap[K[_ >: Nothing <: Any] >: [_]Nothing <: [_]Any] extends
scala.ScalaObject {
private[this] val map: Map[Any,Any] = _;
private def this(map: Map[Any, Any] = Map[Any, Any]()):
dependentMap.DependentMap[K] = {
DependentMap.super.this();
()
};
def +[V >: _root_.scala.Nothing <: _root_.scala.Any](k: K[V], v: V) =
new DependentMap(map.$plus(k.$minus$greater(v)))
}
}, pt = ?

Re: Compiler Bug?

Added by Landei on 2009-09-19, 21:07

Landei wrote:
>
> Hi!
>
> I was just playing around, trying to get a better idea of higher kinded
> types, so this probably doesn't make much sense:
>
> class DependentMap[K[_]] private (map:Map[Any,Any] = Map[Any,Any]()) {
> def +[V](k:K[V], v:V) = new DependentMap(map + (k -> v))
> }
>
> However, it also seems to break the compiler (this is Scala 2.8, I just
> updated to the last Netbeans-Plugin), see the stacktrace below.
>
> Cheers,
> Daniel
>
> --snip--
>

OK, I filed a ticket: https://lampsvn.epfl.ch/trac/scala/ticket/2367

Cheers,
Daniel

compiler bug?

Added by H-star Development on 2010-07-30, 20:07

i get this error:
Information:Compilation completed with 3 errors and 24 warnings
Information:3 errors
Information:24 warnings
Error: class file needed by CompressedPositions is missing.
Error:reference type _$3 of [A<:
<?>]scala.collection.generic.CanBuildFrom[scala.collection.IterableView.Coll,A,scala.collection.IterableView[A,Iterable[_]]]
refers to nonexisting symbol.
Error:one error found

but it's fixed if i replace this
def viewOnPositions = {
//to save huge amounts of memory, don't create a set - use a simple
view. and don't use a val because views cause trouble when serialized :)
compressedData.view.map(e => bounding.pointAtIndex(e))
}

by this

def viewOnPositions:Iterable[Position] = {
//to save huge amounts of memory, don't create a set - use a simple
view. and don't use a val because views cause trouble when serialized :)
compressedData.view.map(e => bounding.pointAtIndex(e))
}

or this:
def viewOnPositions = {
//to save huge amounts of memory, don't create a set - use a simple
view. and don't use a val because views cause trouble when serialized :)
compressedData.map(e => bounding.pointAtIndex(e))
}

is it a compiler bug? or does my idea mess it up?

Compiler bug?

Added by T. Sergey on 2010-09-09, 00:17

Hi!
When I try to compile the following code:

package my
class Test {
def this(un: Int) = {
this()
def test(acc: Array[Byte]) = {
acc.map((f: Byte) => 42)
}
}
}
object Test {
def main(args: Array[String]): Unit = {
val q = new Test(42)
}
}

I have no compiling errors, but when I running it I have exception:

java.lang.VerifyError: (class: my/Test, method: test$1 signature: ([B)[I) Incompatible argument to function
Exception in thread "main"

What am I doing wrong?

Scala-2.8
JVM-1.6
Win-7-32bit

P.S. Руки из жопы — чума, с которой сражаются люди в белых халатах

Compiler bug?

Added by nilskp on 2010-09-21, 13:47
Yesterday a user emailed me a stack trace that occurs when he uses O/R Broker:
java.lang.IllegalAccessError: tried to access field
org.orbroker.Token.id from class org.orbroker.Executable$class
[error] at org.orbroker.Executable$class.executeForKey(Executable.scala:29)
[error] at org.orbroker.Transaction.executeForKey(Transactional.scala:11)
[error] at org.orbroker.Executable$class.execute(Executable.scala:17)
[error] at org.orbroker.Transaction.execute(Transactional.scala:11)

It appears that when compiling with -optimise, the compiler (at least in this case) will access a private field directly instead of through the public accessor.



The class Token has this javap output:

public final class org.orbroker.Token extends java.lang.Object implements scala.ScalaObject{


    private final scala.Symbol id;

    public final scala.collection.immutable.Map parmConverters;
    private final scala.Either extractor;
    public static final org.orbroker.Token apply(scala.Symbol, scala.collection.Seq);
    public static final org.orbroker.Token apply(scala.Symbol, org.orbroker.QueryExtractor, scala.collection.Seq);



    public scala.Symbol id();
    public scala.collection.immutable.Map parmConverters();
    public scala.Either extractor();
    public java.lang.Object convert(java.lang.Object);



    public org.orbroker.Token(scala.Symbol, org.orbroker.QueryExtractor, scala.collection.immutable.Map);
}

And the code accessing it, looks like this (when compiled with -optimise):



getfield        #44; //Field org/orbroker/Token.id:Lscala/Symbol;

I assume this is bug, unless there's something I'm seriously misunderstanding.



(This is compiled and run with Scala 2.8.0-final)



Nils

Re: Compiler bug?

Added by nilskp on 2010-09-22, 15:27
I have now identified this as being a bug only in Eclipse, not scalac. This is surprising to me though, as I thought Eclipse was using the same exact compiler. Unless Eclipse by default uses some scalac non-default compiler flag.

On Tue, Sep 21, 2010 at 7:36 AM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
Yesterday a user emailed me a stack trace that occurs when he uses O/R Broker:
java.lang.IllegalAccessError: tried to access field
org.orbroker.Token.id from class org.orbroker.Executable$class
[error] at org.orbroker.Executable$class.executeForKey(Executable.scala:29)
[error] at org.orbroker.Transaction.executeForKey(Transactional.scala:11)
[error] at org.orbroker.Executable$class.execute(Executable.scala:17)
[error] at org.orbroker.Transaction.execute(Transactional.scala:11)

It appears that when compiling with -optimise, the compiler (at least in this case) will access a private field directly instead of through the public accessor.




The class Token has this javap output:

public final class org.orbroker.Token extends java.lang.Object implements scala.ScalaObject{



    private final scala.Symbol id;

    public final scala.collection.immutable.Map parmConverters;
    private final scala.Either extractor;
    public static final org.orbroker.Token apply(scala.Symbol, scala.collection.Seq);
    public static final org.orbroker.Token apply(scala.Symbol, org.orbroker.QueryExtractor, scala.collection.Seq);




    public scala.Symbol id();
    public scala.collection.immutable.Map parmConverters();
    public scala.Either extractor();
    public java.lang.Object convert(java.lang.Object);




    public org.orbroker.Token(scala.Symbol, org.orbroker.QueryExtractor, scala.collection.immutable.Map);
}

And the code accessing it, looks like this (when compiled with -optimise):




getfield        #44; //Field org/orbroker/Token.id:Lscala/Symbol;

I assume this is bug, unless there's something I'm seriously misunderstanding.




(This is compiled and run with Scala 2.8.0-final)




Nils

Re: Re: Compiler bug?

Added by milessabin on 2010-09-22, 15:37

On Wed, Sep 22, 2010 at 3:25 PM, Nils Kilden-Pedersen wrote:
> I have now identified this as being a bug only in Eclipse, not scalac. This
> is surprising to me though, as I thought Eclipse was using the same exact
> compiler. Unless Eclipse by default uses some scalac non-default compiler
> flag.

I think it's very unlikely that you'd see a difference in generated
code between command-line scalac and a build in Eclipse (at least, if
it's a clean build) using the build manager.

Can you try and extract out a self-contained reproducible example of
this for us?

Cheers,

Miles

Re: Re: Compiler bug?

Added by nilskp on 2010-09-22, 20:47
On Wed, Sep 22, 2010 at 9:30 AM, Miles Sabin <miles [at] milessabin [dot] com> wrote:
On Wed, Sep 22, 2010 at 3:25 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
> I have now identified this as being a bug only in Eclipse, not scalac. This
> is surprising to me though, as I thought Eclipse was using the same exact
> compiler. Unless Eclipse by default uses some scalac non-default compiler
> flag.

I think it's very unlikely that you'd see a difference in generated
code between command-line scalac and a build in Eclipse (at least, if
it's a clean build) using the build manager.

Can you try and extract out a self-contained reproducible example of
this for us?

I'm probably being dense, but I'm logged in and cannot seem to find a button to create a ticket.
https://www.assembla.com/spaces/scala-ide/tickets

Anyway, I'm now unable to reproduce this in the previous form, however still able to get scalac and Eclipse to reproduce different compile results with -optimise enabled:

final class Foo private (val name: String)

trait Bar {
  def sayHello(foo: Foo) = println(foo.name)
}

This is the javap output from Eclipse:
>javap -private Foo
Compiled from "Foo.scala"
public final class Foo extends java.lang.Object implements scala.ScalaObject{
    private final java.lang.String name;
    public java.lang.String name();
    private Foo(java.lang.String);
}
>javap -c Bar$class
Compiled from "Foo.scala"
public abstract class Bar$class extends java.lang.Object{
public static void sayHello(Bar, Foo);
  Code:
   0:   getstatic       #11; //Field scala/Predef$.MODULE$:Lscala/Predef$;
   3:   aload_1
   4:   invokevirtual   #18; //Method Foo.name:()Ljava/lang/String;
   7:   invokevirtual   #22; //Method scala/Predef$.println:(Ljava/lang/Object;)V
   10:  return

public static void $init$(Bar);
  Code:
   0:   return

}

And then compiling with scalac:
>javap -private Foo
Compiled from "Foo.scala"
public final class Foo extends java.lang.Object implements scala.ScalaObject{
    public final java.lang.String name;
    public java.lang.String name();
    private Foo(java.lang.String);
}
>javap -c Bar$class
Compiled from "Foo.scala"
public abstract class Bar$class extends java.lang.Object{
public static void sayHello(Bar, Foo);
  Code:
   0:   aload_1
   1:   getfield        #12; //Field Foo.name:Ljava/lang/String;
   4:   astore_2
   5:   getstatic       #18; //Field scala/Console$.MODULE$:Lscala/Console$;
   8:   aload_2
   9:   invokevirtual   #22; //Method scala/Console$.println:(Ljava/lang/Object;)V
   12:  return

public static void $init$(Bar);
  Code:
   0:   return

}

I maintain that Eclipse has produced a version with a private field and a getfield access (evidence for this is the 3.0.2 download which was exported from Eclipse), and I'm hoping that whatever is causing this discrepancy between scalac and Eclipse can lead to the real bug.

Could there be some inconsistent interaction going on between the two compilers employed by Eclipse?

Nils

Re: Re: Compiler bug?

Added by milessabin on 2010-09-23, 09:57

On Wed, Sep 22, 2010 at 8:41 PM, Nils Kilden-Pedersen wrote:
> And then compiling with scalac:
>>javap -private Foo
> Compiled from "Foo.scala"
> public final class Foo extends java.lang.Object implements
> scala.ScalaObject{
>     public final java.lang.String name;
>     public java.lang.String name();
>     private Foo(java.lang.String);
> }

That doesn't look right to me ... what version of scalac do you have
on your path?

With 2.8.0.final I get,

miles@lewis:scala$ scalac -version
Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
miles@lewis:scala$ scalac internals.scala
miles@lewis:scala$ javap -private Foo
Compiled from "internals.scala"
public final class Foo extends java.lang.Object implements scala.ScalaObject{
private final java.lang.String name;
public java.lang.String name();
private Foo(java.lang.String);
}

ie. exactly the same as the SDT for 2.8.0.final.

Cheers,

Miles

Re: Re: Compiler bug?

Added by nilskp on 2010-09-23, 13:07
On Thu, Sep 23, 2010 at 3:47 AM, Miles Sabin <miles [at] milessabin [dot] com> wrote:
On Wed, Sep 22, 2010 at 8:41 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
> And then compiling with scalac:
>>javap -private Foo
> Compiled from "Foo.scala"
> public final class Foo extends java.lang.Object implements
> scala.ScalaObject{
>     public final java.lang.String name;
>     public java.lang.String name();
>     private Foo(java.lang.String);
> }

That doesn't look right to me ... what version of scalac do you have
on your path?

>scalac -version
Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
 

With 2.8.0.final I get,

miles@lewis:scala$ scalac -version
Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
miles@lewis:scala$ scalac internals.scala
miles@lewis:scala$ javap -private Foo
Compiled from "internals.scala"
public final class Foo extends java.lang.Object implements scala.ScalaObject{
   private final java.lang.String name;
   public java.lang.String name();
   private Foo(java.lang.String);
}

ie. exactly the same as the SDT for 2.8.0.final.

With -optimise?

Re: Re: Compiler bug?

Added by milessabin on 2010-09-23, 13:57

On Thu, Sep 23, 2010 at 1:02 PM, Nils Kilden-Pedersen wrote:
>> That doesn't look right to me ... what version of scalac do you have
>> on your path?
>
>>scalac -version
> Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
>
>>
>> With 2.8.0.final I get,
>>
>> miles@lewis:scala$ scalac -version
>> Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
>> miles@lewis:scala$ scalac internals.scala
>> miles@lewis:scala$ javap -private Foo
>> Compiled from "internals.scala"
>> public final class Foo extends java.lang.Object implements
>> scala.ScalaObject{
>>    private final java.lang.String name;
>>    public java.lang.String name();
>>    private Foo(java.lang.String);
>> }
>>
>> ie. exactly the same as the SDT for 2.8.0.final.
>
> With -optimise?

No, without -optimize. With -optimize I get the same as you.

That suggests that you don't have optimization enabled for your
Eclipse build (or that Eclipse isn't honouring the switch if you have)
... can you check?

Cheers,

Miles

Re: Re: Compiler bug?

Added by nilskp on 2010-09-23, 17:17
On Thu, Sep 23, 2010 at 7:49 AM, Miles Sabin <miles [at] milessabin [dot] com> wrote:
On Thu, Sep 23, 2010 at 1:02 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
>> That doesn't look right to me ... what version of scalac do you have
>> on your path?
>
>>scalac -version
> Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
>
>>
>> With 2.8.0.final I get,
>>
>> miles@lewis:scala$ scalac -version
>> Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
>> miles@lewis:scala$ scalac internals.scala
>> miles@lewis:scala$ javap -private Foo
>> Compiled from "internals.scala"
>> public final class Foo extends java.lang.Object implements
>> scala.ScalaObject{
>>    private final java.lang.String name;
>>    public java.lang.String name();
>>    private Foo(java.lang.String);
>> }
>>
>> ie. exactly the same as the SDT for 2.8.0.final.
>
> With -optimise?

No, without -optimize. With -optimize I get the same as you.

That suggests that you don't have optimization enabled for your
Eclipse build (or that Eclipse isn't honouring the switch if you have)
... can you check?

If you read my previous posts, I have always stated with -optimise. For both compilers. So yes, optimise is enabled on my Eclipse Scala compiler setting.

Re: Re: Compiler bug?

Added by Iulian Dragos 2 on 2010-09-23, 14:57
I don't know if it's relevant, but note that the optimizer may turn private fields into public ones if it inlines some method /in the same compilation unit/. So if you have some old classfiles, and you moved a class to another file without recompiling both files, you may see such problems.
iulian

On Thu, Sep 23, 2010 at 2:49 PM, Miles Sabin <miles [at] milessabin [dot] com> wrote:
On Thu, Sep 23, 2010 at 1:02 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
>> That doesn't look right to me ... what version of scalac do you have
>> on your path?
>
>>scalac -version
> Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
>
>>
>> With 2.8.0.final I get,
>>
>> miles@lewis:scala$ scalac -version
>> Scala compiler version 2.8.0.final -- Copyright 2002-2010, LAMP/EPFL
>> miles@lewis:scala$ scalac internals.scala
>> miles@lewis:scala$ javap -private Foo
>> Compiled from "internals.scala"
>> public final class Foo extends java.lang.Object implements
>> scala.ScalaObject{
>>    private final java.lang.String name;
>>    public java.lang.String name();
>>    private Foo(java.lang.String);
>> }
>>
>> ie. exactly the same as the SDT for 2.8.0.final.
>
> With -optimise?

No, without -optimize. With -optimize I get the same as you.

That suggests that you don't have optimization enabled for your
Eclipse build (or that Eclipse isn't honouring the switch if you have)
... can you check?

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles [at] milessabin [dot] com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Re: Re: Compiler bug?

Added by nilskp on 2010-10-07, 20:57
On Thu, Sep 23, 2010 at 8:51 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
I don't know if it's relevant, but note that the optimizer may turn private fields into public ones if it inlines some method /in the same compilation unit/. So if you have some old classfiles, and you moved a class to another file without recompiling both files, you may see such problems.
iulian

Sorry to bump this, but this specific feature of -optimise doesn't really sit well with me.
First, I think it's unnecessary, as most JVMs already perform this sort of inlining.
Secondarily, code compiled against the, now public, field will access the field, not the synthetic accessor method (certainly for Java, and for Scala in the same compile, but I'm unsure if separate compile). This leaves future changes to accessor method, where inlining no longer applies, inaccessible by code compiled against the previous version.


Nils

Re: Re: Compiler bug?

Added by Iulian Dragos 2 on 2010-10-12, 10:07


On Thu, Oct 7, 2010 at 9:52 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
On Thu, Sep 23, 2010 at 8:51 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
I don't know if it's relevant, but note that the optimizer may turn private fields into public ones if it inlines some method /in the same compilation unit/. So if you have some old classfiles, and you moved a class to another file without recompiling both files, you may see such problems.
iulian

Sorry to bump this, but this specific feature of -optimise doesn't really sit well with me.
First, I think it's unnecessary, as most JVMs already perform this sort of inlining.

The inlining is necessary for the other optimisations that scalac performs. Inlining itself does not buy us much, but closure elimination does. Without looking at what a getter returns, we can't infer much about what closures can be completely eliminated. Same goes for implicits that create short-lived objects.  
Secondarily, code compiled against the, now public, field will access the field, not the synthetic accessor method (certainly for Java, and for Scala in the same compile, but I'm unsure if separate compile).

For Java, this should not be the case. The syntax for calling a getter or accessing a field is different. I assume that if you go for the field, you know what you're doing. Scala will always use the getter (unless optimized itself), because the type information for a class is not altered (only the bytecode representation).  
This leaves future changes to accessor method, where inlining no longer applies, inaccessible by code compiled against the previous version.

This could only happen for accesses in the same compilation unit, therefore the definition and use are compiled together and optimized (or not) together. Should not be a problem, really.
As I explained before, this sort of inlining is important for other optimizations.
iulian 


Nils




--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Re: Re: Compiler bug?

Added by nilskp on 2010-10-13, 13:07
On Tue, Oct 12, 2010 at 3:55 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
This could only happen for accesses in the same compilation unit, therefore the definition and use are compiled together and optimized (or not) together. Should not be a problem, really.

Not sure if you can give an authoritative answer to this, but would you recommend that providers of third party Scala libraries compile with -optimise, or is the benefit primarily when code is compiled in the same unit?
I assume that some optimizations are lost when the library is compiled on its own, but I don't have a good idea of what fraction that is.

Re: Re: Compiler bug?

Added by Jesper Nordenberg on 2010-10-12, 18:17
Sorry for getting slightly off topic, but is there some documentation about which optimizations scalac can perform and how to structure code so that the optimizations are applied? I believe I've read some paper you wrote about it (can't find it though), is it still up to date?

/Jesper Nordenberg

--- On Tue, 10/12/10, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
The inlining is necessary for the other optimisations that scalac performs. Inlining itself does not buy us much, but closure elimination does. Without looking at what a getter returns, we can't infer much about what closures can be completely eliminated. Same goes for implicits that create short-lived objects.

Re: Re: Compiler bug?

Added by Iulian Dragos 2 on 2010-10-13, 10:27


On Tue, Oct 12, 2010 at 7:09 PM, Jesper Nordenberg <megagurka [at] yahoo [dot] com> wrote:
Sorry for getting slightly off topic, but is there some documentation about which optimizations scalac can perform and how to structure code so that the optimizations are applied? I believe I've read some paper you wrote about it (can't find it though), is it still up to date?

The most up to date would be my thesis, but I won't bore you with that. A more concise description is found in my paper on optimizations. If the link doesn't work, let me know and I'll put it on my web page.
iulian 

/Jesper Nordenberg

--- On Tue, 10/12/10, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
The inlining is necessary for the other optimisations that scalac performs. Inlining itself does not buy us much, but closure elimination does. Without looking at what a getter returns, we can't infer much about what closures can be completely eliminated. Same goes for implicits that create short-lived objects.




--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Re: Re: Compiler bug?

Added by Jesper Nordenberg on 2010-10-13, 17:37
Thanks. Looking forward to reading your thesis.

/Jesper Nordenberg

--- On Wed, 10/13/10, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:

From: iulian dragos <iulian [dot] dragos [at] epfl [dot] ch>
Subject: Re: [scala-internals] Re: Compiler bug?
To: "Jesper Nordenberg" <megagurka [at] yahoo [dot] com>
Cc: scala-internals [at] listes [dot] epfl [dot] ch
Date: Wednesday, October 13, 2010, 11:19 AM



On Tue, Oct 12, 2010 at 7:09 PM, Jesper Nordenberg <megagurka [at] yahoo [dot] com" target="_blank" href="/mc/compose?to=megagurka [at] yahoo [dot] com" rel="nofollow">megagurka [at] yahoo [dot] com> wrote:
Sorry for getting slightly off topic, but is there some documentation about which optimizations scalac can perform and how to structure code so that the optimizations are applied? I believe I've read some paper you wrote about it (can't find it though), is it still up to date?

The most up to date would be my thesis, but I won't bore you with that. A more concise description is found in my paper on optimizations. If the link doesn't work, let me know and I'll put it on my web page.
iulian 

/Jesper Nordenberg

--- On Tue, 10/12/10, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch" target="_blank" href="/mc/compose?to=iulian [dot] dragos [at] epfl [dot] ch" rel="nofollow">iulian [dot] dragos [at] epfl [dot] ch> wrote:
The inlining is necessary for the other optimisations that scalac performs. Inlining itself does not buy us much, but closure elimination does. Without looking at what a getter returns, we can't infer much about what closures can be completely eliminated. Same goes for implicits that create short-lived objects.




--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Re: Re: Compiler bug?

Added by extempore on 2010-10-12, 18:47

On Tue, Oct 12, 2010 at 10:09:12AM -0700, Jesper Nordenberg wrote:
> Sorry for getting slightly off topic, but is there some documentation
> about which optimizations scalac can perform and how to structure code
> so that the optimizations are applied? I believe I've read some paper
> you wrote about it (can't find it though), is it still up to date?

I would say to read his thesis, but unless I'm missing it there's no
link to download it yet. Soon, I imagine.

http://library.epfl.ch/en/theses/?nr=4820

I had it bound into a book. All it needs now is the autograph.

Re: Re: Compiler bug?

Added by nilskp on 2010-10-12, 15:47
On Tue, Oct 12, 2010 at 3:55 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
This could only happen for accesses in the same compilation unit, therefore the definition and use are compiled together and optimized (or not) together. Should not be a problem, really.

Ok, that is what I would expect, but I was a bit worried that it might not be the case.

As I explained before, this sort of inlining is important for other optimizations.

That's fine, although I still think it's problematic that encapsulation is negated for Java, but that's true for package private too.

Re: Re: Compiler bug?

Added by nilskp on 2010-09-23, 17:27
On Thu, Sep 23, 2010 at 8:51 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
I don't know if it's relevant, but note that the optimizer may turn private fields into public ones if it inlines some method /in the same compilation unit/. So if you have some old classfiles, and you moved a class to another file without recompiling both files, you may see such problems.

I'm beginning to think this is the problem. Eclipse plugin tries to do incremental compiles, and lots of people report that to be unreliable. I think that could explain my original post.

Re: Re: Compiler bug?

Added by Iulian Dragos 2 on 2010-09-24, 07:27


On Thu, Sep 23, 2010 at 6:17 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
On Thu, Sep 23, 2010 at 8:51 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
I don't know if it's relevant, but note that the optimizer may turn private fields into public ones if it inlines some method /in the same compilation unit/. So if you have some old classfiles, and you moved a class to another file without recompiling both files, you may see such problems.

I'm beginning to think this is the problem. Eclipse plugin tries to do incremental compiles, and lots of people report that to be unreliable. I think that could explain my original post.

But did you move a class to another file? The same thing would happen without the eclipse build manager, under this conditions. 
iulian 


--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Re: Re: Compiler bug?

Added by nilskp on 2010-09-24, 13:07
On Fri, Sep 24, 2010 at 1:21 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:


On Thu, Sep 23, 2010 at 6:17 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
On Thu, Sep 23, 2010 at 8:51 AM, iulian dragos <iulian [dot] dragos [at] epfl [dot] ch> wrote:
I don't know if it's relevant, but note that the optimizer may turn private fields into public ones if it inlines some method /in the same compilation unit/. So if you have some old classfiles, and you moved a class to another file without recompiling both files, you may see such problems.

I'm beginning to think this is the problem. Eclipse plugin tries to do incremental compiles, and lots of people report that to be unreliable. I think that could explain my original post.

But did you move a class to another file? The same thing would happen without the eclipse build manager, under this conditions. 

Frankly, I don't recall, but everything is within a single project, so I was, naively perhaps, expecting Eclipse to make sure everything was cleanly built. I should of course have a "clean" (complete rebuild) before exporting to jar.

My next releases will be compiled externally, so at this point, I don't feel like spending more time tracking this down.

Thanks for looking into this.

Re: Re: Compiler bug?

Added by milessabin on 2010-09-23, 17:47

On Thu, Sep 23, 2010 at 5:17 PM, Nils Kilden-Pedersen wrote:
> On Thu, Sep 23, 2010 at 8:51 AM, iulian dragos
> wrote:
>>
>> I don't know if it's relevant, but note that the optimizer may turn
>> private fields into public ones if it inlines some method /in the same
>> compilation unit/. So if you have some old classfiles, and you moved a class
>> to another file without recompiling both files, you may see such problems.
>
> I'm beginning to think this is the problem. Eclipse plugin tries to do
> incremental compiles, and lots of people report that to be unreliable. I
> think that could explain my original post.

In that case this would be a problem you could reproduce using command
line scalac with the -Ybuilder-debug:refined switch.

Cheers,

Miles

Re: Re: Compiler bug?

Added by milessabin on 2010-09-23, 09:47

On Wed, Sep 22, 2010 at 8:41 PM, Nils Kilden-Pedersen wrote:
> I'm probably being dense, but I'm logged in and cannot seem to find a button
> to create a ticket.
> https://www.assembla.com/spaces/scala-ide/tickets

You need to "Watch" the project ...

Cheers,

Miles

Re: Re: Compiler bug?

Added by nilskp on 2010-09-22, 16:57
On Wed, Sep 22, 2010 at 9:30 AM, Miles Sabin <miles [at] milessabin [dot] com> wrote:
On Wed, Sep 22, 2010 at 3:25 PM, Nils Kilden-Pedersen <nilskp [at] gmail [dot] com> wrote:
> I have now identified this as being a bug only in Eclipse, not scalac. This
> is surprising to me though, as I thought Eclipse was using the same exact
> compiler. Unless Eclipse by default uses some scalac non-default compiler
> flag.

I think it's very unlikely that you'd see a difference in generated
code between command-line scalac and a build in Eclipse (at least, if
it's a clean build) using the build manager.

Can you try and extract out a self-contained reproducible example of
this for us?

Yes, I already have a condensed reproducable example. I'll submit a bug report later today when I have time.

BTW, I'm on Helios with Helios plugin, if that makes a difference.

 

Cheers,


Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: miles [at] milessabin [dot] com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Re: Compiler bug?

Added by extempore on 2010-09-09, 04:07

On Thu, Sep 09, 2010 at 03:11:49AM +0400, T. Sergey wrote:
> I have no compiling errors, but when I running it I have exception:
>
> java.lang.VerifyError: (class: my/Test, method: test$1 signature:
> ([B)[I) Incompatible argument to function Exception in thread "main"
>
> What am I doing wrong?

A VerifyError is always a compiler bug, but if we can define what you're
doing wrong as the avoidable code which induces it, then you are
defining a function inside an auxiliary constructor, and that is wrong.

https://lampsvn.epfl.ch/trac/scala/ticket/3832

Re: compiler bug?

Added by Naftoli Gugenheim on 2010-08-01, 22:47
Usually this error means you are referencing a class in the classpath, but that class file couldn't be properly loaded due to the fact that it in turn references another class which is not on the classpath. What happens if you write this
   compressedData.view.map(e => bounding.pointAtIndex(e))

in the REPL? What is the type of the expression?

On Fri, Jul 30, 2010 at 3:05 PM, HamsterofDeath <h-star [at] gmx [dot] de> wrote:
 i get this error:
Information:Compilation completed with 3 errors and 24 warnings
Information:3 errors
Information:24 warnings
Error: class file needed by CompressedPositions is missing.
Error:reference type _$3 of [A<:
<?>]scala.collection.generic.CanBuildFrom[scala.collection.IterableView.Coll,A,scala.collection.IterableView[A,Iterable[_]]]
refers to nonexisting symbol.
Error:one error found

but it's fixed if i replace this
 def viewOnPositions = {
   //to save huge amounts of memory, don't create a set - use a simple
view. and don't use a val because views cause trouble when serialized :)
   compressedData.view.map(e => bounding.pointAtIndex(e))
 }

by this

 def viewOnPositions:Iterable[Position] = {
   //to save huge amounts of memory, don't create a set - use a simple
view. and don't use a val because views cause trouble when serialized :)
   compressedData.view.map(e => bounding.pointAtIndex(e))
 }


or this:
 def viewOnPositions = {
   //to save huge amounts of memory, don't create a set - use a simple
view. and don't use a val because views cause trouble when serialized :)
   compressedData.map(e => bounding.pointAtIndex(e))
 }

is it a compiler bug? or does my idea mess it up?



compiler bug?

Added by Sadek Drobi on 2011-01-21, 00:37
scala> trait Weired{val i=j; val j:Int=1}defined trait Weired
scala> object W extends Weireddefined module W
scala> W.ires11: Int = 0
scala> trait MoreWeired{val (i,_)=j; val j:(Int,Int)=(1,2)}defined trait MoreWeired
scala> object MW extends MoreWeired                        defined module MW
scala> MW.iscala.MatchError: null at MoreWeired$class.$init$(<console>:5) at MW$.<init>(<console>:6) at MW$.<clinit>(<console>) at .<init>(<console>:8) at .<clinit>(<console>) at RequestResult$.<init>(<console>:9) at RequestResult$.<clinit>(<console>) at RequestResult$scala_repl_result(<console>) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at scala.tools.nsc.Interpreter$Request$$anonfun$loadAndRun$1$$anonfun$apply$17.apply(Interpreter.scala:988) at scala.tools.nsc.Interpreter$Request$$anonfun$loadAndRun$1$$anonfun$apply$17.apply(Interpreter.scala:...

--
www.sadekdrobi.com
ʎdoɹʇuǝ

Compiler bug?

Added by Rodrigo Cano on 2011-12-01, 03:47
Hi there,
I'm hitting a mysterious :
error while loading Vector$1, class file '/home/rodrigo/Programs/jdk1.7.0/jre/lib/rt.jar(java/util/Vector$1.class)' is broken (key not found: E)

while trying to write some wrappers around JEditorPane. No idea of how to get more info out of the compiler. I have a self contained sbt project with 5 classes of which one is to blame (if excluded, the project compiles fine) which I'll attach in case someone is willing to investigate. In the attached zip, the culprit is JEditorPaneReactive.scala.

Cheers.


Re: Compiler bug?

Added by Rodrigo Cano on 2011-12-01, 04:17
And of course, the forgotten zip :-)

On Thu, Dec 1, 2011 at 12:44 AM, Rodrigo Cano <ioniviil [at] gmail [dot] com> wrote:
Hi there,
I'm hitting a mysterious :
error while loading Vector$1, class file '/home/rodrigo/Programs/jdk1.7.0/jre/lib/rt.jar(java/util/Vector$1.class)' is broken (key not found: E)

while trying to write some wrappers around JEditorPane. No idea of how to get more info out of the compiler. I have a self contained sbt project with 5 classes of which one is to blame (if excluded, the project compiles fine) which I'll attach in case someone is willing to investigate. In the attached zip, the culprit is JEditorPaneReactive.scala.

Cheers.



compiler bug?

Added by H-star Development on 2012-01-12, 00:01

i guess i finally found one :)
run this:

object ImplicitResolutionOne {
implicit def parse(s: String) = Integer.parseInt(s)

implicit def parse(s: ImplicitResolutionOne) = 1

implicit def parse(s: ImplicitResolutionTwo) = 2
}

class ImplicitResolutionOne(val str: String)

object ImplicitResolutionTwo {
implicit def parse(s: ImplicitResolutionOne) = 3

implicit def parse(s: ImplicitResolutionTwo) = 4
}

class ImplicitResolutionTwo(val str: String)

object Caller {
import ImplicitResolutionTwo._
def main(args: Array[String]) {
{
val x: Int = new ImplicitResolutionOne("5")
implicit def parse(i: ImplicitResolutionOne) = 5;//magic line
println(x)
}
}
}

then remove the magic line and run again.
suddenly another implicit is picked, but i don't see a reason why it
should be.

Re: Re: Compiler bug?

Added by Jason Zaugg on 2011-12-01, 08:17
Hi Rodrigo,
Scala Swing is not yet compatible with JDK 1.7. There were changes in the generic signatures in the java.awt._, and a single distribution of Scala currently can't compile against both the old and the new one.
You can build with JDK 1.6 and still use 1.7 at runtime.

-jason

On Thu, Dec 1, 2011 at 4:13 AM, Rodrigo Cano <ioniviil [at] gmail [dot] com> wrote:
And of course, the forgotten zip :-)

On Thu, Dec 1, 2011 at 12:44 AM, Rodrigo Cano <ioniviil [at] gmail [dot] com> wrote:
Hi there,
I'm hitting a mysterious :
error while loading Vector$1, class file '/home/rodrigo/Programs/jdk1.7.0/jre/lib/rt.jar(java/util/Vector$1.class)' is broken (key not found: E)

while trying to write some wrappers around JEditorPane. No idea of how to get more info out of the compiler. I have a self contained sbt project with 5 classes of which one is to blame (if excluded, the project compiles fine) which I'll attach in case someone is willing to investigate. In the attached zip, the culprit is JEditorPaneReactive.scala.

Cheers.




Re: compiler bug?

Added by dcsobral on 2011-01-21, 03:07
I don't see any problem. The body of a trait or class mingles the declaration of its members with the initialization. The declaration is taken as a whole -- since j was declared, i is allowed to reference it. Initialization is done sequentially, like in any other code.
Say, for instance, you have this:
class MoreWeird {  var i: Int = _  var j: Tuple2[Int, Int] = _
  def this(dummy: Unit) = {     this()    j match {      case (x, _) => i = x    }    j = (1,2)  }}
What do you expect to happen when you call "new MoreWeird(())"? Well, that's what your class is doing.

On Thu, Jan 20, 2011 at 21:28, Sadek Drobi <sadek [dot] drobi [at] gmail [dot] com> wrote:
scala> trait Weired{val i=j; val j:Int=1}defined trait Weired
scala> object W extends Weireddefined module W
scala> W.ires11: Int = 0
scala> trait MoreWeired{val (i,_)=j; val j:(Int,Int)=(1,2)}defined trait MoreWeired
scala> object MW extends MoreWeired                        defined module MW
scala> MW.iscala.MatchError: null at MoreWeired$class.$init$(<console>:5) at MW$.<init>(<console>:6) at MW$.<clinit>(<console>) at .<init>(<console>:8) at .<clinit>(<console>) at RequestResult$.<init>(<console>:9) at RequestResult$.<clinit>(<console>) at RequestResult$scala_repl_result(<console>) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at scala.tools.nsc.Interpreter$Request$$anonfun$loadAndRun$1$$anonfun$apply$17.apply(Interpreter.scala:988) at scala.tools.nsc.Interpreter$Request$$anonfun$loadAndRun$1$$anonfun$apply$17.apply(Interpreter.scala:...

--
www.sadekdrobi.com
ʎdoɹʇuǝ



--
Daniel C. Sobral

I travel to the future all the time.

Re: compiler bug?

Added by Aaron Novstrup on 2011-01-21, 03:37

Those of us who understand more of what's going on "under the hood" need
to be careful not to assume that it's correct or unsurprising just
because we understand it. It certainly isn't intuitive that `val i = j`
works as a forward reference but that `val (i, _) = j` does not, and I
for one see that as a problem. It's all too easy for people to come
away from inconsistencies like this with the conclusion that Scala is
too complex.

On 01/20/2011 05:59 PM, Daniel Sobral wrote:
> I don't see any problem. The body of a trait or class mingles the
> declaration of its members with the initialization. The declaration is taken
> as a whole -- since j was declared, i is allowed to reference it.
> Initialization is done sequentially, like in any other code.
>
> Say, for instance, you have this:
>
> class MoreWeird {
> var i: Int = _
> var j: Tuple2[Int, Int] = _
>
> def this(dummy: Unit) = {
> this()
> j match {
> case (x, _) => i = x
> }
> j = (1,2)
> }
> }
>
> What do you expect to happen when you call "new MoreWeird(())"? Well, that's
> what your class is doing.

Re: compiler bug?

Added by Aaron Novstrup on 2011-01-21, 01:07

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

And don't forget:

scala> object AlsoWeird { val j: Any = 1; val (i,_)=j }
defined module AlsoWeird

scala> AlsoWeird.i
scala.MatchError: 1
at AlsoWeird$.(:5)
at AlsoWeird$.()
at .(:7)
at .()

See also
http://scala-programming-language.1934581.n4.nabble.com/Is-MatchError-be....

In my opinion, AlsoWeird should not compile and MoreWeired should
correctly resolve the forward reference.

On 01/20/2011 03:28 PM, Sadek Drobi wrote:
> scala> trait Weired{val i=j; val j:Int=1}
> defined trait Weired
>
> scala> object W extends Weired
> defined module W
>
> scala> W.i
> res11: Int = 0
>
> scala> trait MoreWeired{val (i,_)=j; val j:(Int,Int)=(1,2)}
> defined trait MoreWeired
>
> scala> object MW extends MoreWeired
> defined module MW
>
> scala> MW.i
> scala.MatchError: null
> at MoreWeired$class.$init$(:5)
> at MW$.(:6)
> at MW$.()
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk04zF0ACgkQW6MGPLg7ninZBACeJDkqwIut9y2r822P+Vmn5u/p
SpoAnA0ryobd9cr7YczOzrc9HfXeaJqD
=/xuF
-----END PGP SIGNATURE-----

Re: compiler bug?

Added by Aaron Novstrup on 2011-01-21, 03:47

It seems I missed the point of your original post -- the forward
reference doesn't work in either case. In this case, I'd say this
should be a compile error (forward references make no sense and should
therefore be illegal). If you must have a forward reference, you can
define `j` as a method.

On 01/20/2011 03:59 PM, Aaron Novstrup wrote:
> And don't forget:
>
> scala> object AlsoWeird { val j: Any = 1; val (i,_)=j }
> defined module AlsoWeird
>
> scala> AlsoWeird.i
> scala.MatchError: 1
> at AlsoWeird$.(:5)
> at AlsoWeird$.()
> at .(:7)
> at .()
>
> See also
> http://scala-programming-language.1934581.n4.nabble.com/Is-MatchError-be....
>
> In my opinion, AlsoWeird should not compile and MoreWeired should
> correctly resolve the forward reference.
>
> On 01/20/2011 03:28 PM, Sadek Drobi wrote:
>> scala> trait Weired{val i=j; val j:Int=1}
>> defined trait Weired
>
>> scala> object W extends Weired
>> defined module W
>
>> scala> W.i
>> res11: Int = 0
>
>> scala> trait MoreWeired{val (i,_)=j; val j:(Int,Int)=(1,2)}
>> defined trait MoreWeired
>
>> scala> object MW extends MoreWeired
>> defined module MW
>
>> scala> MW.i
>> scala.MatchError: null
>> at MoreWeired$class.$init$(:5)
>> at MW$.(:6)
>> at MW$.()

Re: compiler bug?

Added by Naftoli Gugenheim on 2011-01-24, 02:27
 Thu, Jan 20, 2011 at 9:28 PM, Aaron Novstrup <anovstrup [at] stottlerhenke [dot] com> wrote:
If you must have a forward reference, you can
define `j` as a method.

Or as a lazy val.

Re: compiler bug?

Added by Sadek Drobi on 2011-01-22, 11:17

So should I issue a ticket?

On 21 janv. 2011, at 03:29, Aaron Novstrup wrote:

> It seems I missed the point of your original post -- the forward
> reference doesn't work in either case. In this case, I'd say this
> should be a compile error (forward references make no sense and should
> therefore be illegal). If you must have a forward reference, you can
> define `j` as a method.
>
> On 01/20/2011 03:59 PM, Aaron Novstrup wrote:
>> And don't forget:
>>
>> scala> object AlsoWeird { val j: Any = 1; val (i,_)=j }
>> defined module AlsoWeird
>>
>> scala> AlsoWeird.i
>> scala.MatchError: 1
>> at AlsoWeird$.(:5)
>> at AlsoWeird$.()
>> at .(:7)
>> at .()
>>
>> See also
>> http://scala-programming-language.1934581.n4.nabble.com/Is-MatchError-be....
>>
>> In my opinion, AlsoWeird should not compile and MoreWeired should
>> correctly resolve the forward reference.
>>
>> On 01/20/2011 03:28 PM, Sadek Drobi wrote:
>>> scala> trait Weired{val i=j; val j:Int=1}
>>> defined trait Weired
>>
>>> scala> object W extends Weired
>>> defined module W
>>
>>> scala> W.i
>>> res11: Int = 0
>>
>>> scala> trait MoreWeired{val (i,_)=j; val j:(Int,Int)=(1,2)}
>>> defined trait MoreWeired
>>
>>> scala> object MW extends MoreWeired
>>> defined module MW
>>
>>> scala> MW.i
>>> scala.MatchError: null
>>> at MoreWeired$class.$init$(:5)
>>> at MW$.(:6)
>>> at MW$.()
>

Re: compiler bug?

Added by extempore on 2011-01-22, 11:37

On Sat, Jan 22, 2011 at 11:07:41AM +0100, Sadek Drobi wrote:
> So should I issue a ticket?

Not unless it comes with a thick sheaf of documents showing that you have wrestled
with initialization order a while.

> On 21 janv. 2011, at 03:29, Aaron Novstrup wrote:
>
> > It seems I missed the point of your original post -- the forward
> > reference doesn't work in either case. In this case, I'd say this
> > should be a compile error (forward references make no sense and should
> > therefore be illegal). If you must have a forward reference, you can
> > define `j` as a method.

This is not true. Not that I design a lot of classes like this, but:

trait NotWeird {
val a: Int = b + 1
val b: Int = a + 1
}

object OK extends { override val a = 5 } with NotWeird
object AOK extends { override val b = 5 } with NotWeird

object Test {
def main(args: Array[String]): Unit = {
println(List(OK.a, OK.b, AOK.a, AOK.b) mkString " ")
}
}
// prints: 5 6 6 5

A "forward reference" may or may not be a forward reference. We have inheritance
and overriding here.

Re: compiler bug?

Added by Sadek Drobi on 2011-01-22, 11:47

On 22 janv. 2011, at 11:33, Paul Phillips wrote:

> On Sat, Jan 22, 2011 at 11:07:41AM +0100, Sadek Drobi wrote:
>> So should I issue a ticket?
>
> Not unless it comes with a thick sheaf of documents showing that you have wrestled
> with initialization order a while.
Sorry I didn't get you.

>
>> On 21 janv. 2011, at 03:29, Aaron Novstrup wrote:
>>
>>> It seems I missed the point of your original post -- the forward
>>> reference doesn't work in either case. In this case, I'd say this
>>> should be a compile error (forward references make no sense and should
>>> therefore be illegal). If you must have a forward reference, you can
>>> define `j` as a method.
>
> This is not true. Not that I design a lot of classes like this, but:
>
> trait NotWeird {
> val a: Int = b + 1
> val b: Int = a + 1
> }
>
> object OK extends { override val a = 5 } with NotWeird
> object AOK extends { override val b = 5 } with NotWeird
>
> object Test {
> def main(args: Array[String]): Unit = {
> println(List(OK.a, OK.b, AOK.a, AOK.b) mkString " ")
> }
> }
> // prints: 5 6 6 5
>
> A "forward reference" may or may not be a forward reference. We have inheritance
> and overriding here.
>
> --
> Paul Phillips | Those who can make you believe absurdities
> Analgesic | can make you commit atrocities.
> Empiricist | -- Voltaire
> pp: i haul pills |----------* http://www.improving.org/paulp/ *----------

Re: compiler bug?

Added by Donna Malayeri on 2011-01-22, 11:57
> On Sat, Jan 22, 2011 at 11:07:41AM +0100, Sadek Drobi wrote:
>> So should I issue a ticket?
>
> Not unless it comes with a thick sheaf of documents showing that you have wrestled
> with initialization order a while.
Sorry I didn't get you.

He's saying, "no, this is an extremely complex issue, and I and others have thought about it for a long time, and there are reasons it is the way it currently is.  Please don't file a ticket unless you have also thought it out extensively."
Donna 

Re: compiler bug?

Added by Sadek Drobi on 2011-01-22, 12:47
So I suppose it is not as easy as to give a compiler error on the first executable in the hierarchy that doesn't fix it?It is extremely confusing and can require hours of debugging on complex  traits when it accidentally happens. 



On 22 janv. 2011, at 11:51, Donna Malayeri <lindydonna [at] gmail [dot] com (lindydonna [at] gmail [dot] com" rel="nofollow">lindydonna [at] gmail [dot] com)> wrote:

> On Sat, Jan 22, 2011 at 11:07:41AM +0100, Sadek Drobi wrote:
>> So should I issue a ticket?
>
> Not unless it comes with a thick sheaf of documents showing that you have wrestled
> with initialization order a while.
Sorry I didn't get you.

He's saying, "no, this is an extremely complex issue, and I and others have thought about it for a long time, and there are reasons it is the way it currently is.  Please don't file a ticket unless you have also thought it out extensively."
Donna 

Copyright © 2013 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland