Build errors in Eclipse SDT nightly

On Thu, Oct 15, 2009 at 9:13 AM, Silvio Bierman
wrote:
> The last two nightly builds give me the following error during the build
> after saving changes on a particular source file:

Can you build your project using the command line tools?

If not, can you send me the stack trace associated with the assertion
you're seeing?

> Is this a general bug or should I look into something local? I have tried
> throwing away the classes directory content and the .manager directory.but
> that did not make a difference.

Are you sure you're on trunk? There's no .manager directory any more
... you should be seeing a .scala-dependencies file instead.

Cheers,

Miles

Miles Sabin wrote:
>
> Can you build your project using the command line tools?
>
> If not, can you send me the stack trace associated with the assertion
> you're seeing?
>

The closest to a build with the command line tools I ever got was using the
scalac Ant task. Lately this fails with a stack overflow so I decided to
leave that for what it is now, could be something in my Ant task definition.
As said, a clean build works fine.

At the risk of sounding (even more) stupid: how do I get at the stack trace?

Miles Sabin wrote:
>
> Are you sure you're on trunk? There's no .manager directory any more
> ... you should be seeing a .scala-dependencies file instead.
>

Yes, I am on trunk. The .manager dir was there but empty other than .svn
files. I do have the dependency file so the .manager dir was probably old.

Gr. Silvio

On Thu, Oct 15, 2009 at 10:04 AM, Silvio Bierman
wrote:
> The closest to a build with the command line tools I ever got was using the
> scalac Ant task. Lately this fails with a stack overflow so I decided to
> leave that for what it is now, could be something in my Ant task definition.
> As said, a clean build works fine.

Could you try an ant build with the stack size set appropriately?

> At the risk of sounding (even more) stupid: how do I get at the stack trace?

Where are you seeing that assertion? In the Error Log view?

Cheers,

Miles

On Thursday 15 October 2009 13:09:53 Miles Sabin wrote:
> On Thu, Oct 15, 2009 at 10:04 AM, Silvio Bierman
>
> wrote:
> > The closest to a build with the command line tools I ever got was using
> > the scalac Ant task. Lately this fails with a stack overflow so I decided
> > to leave that for what it is now, could be something in my Ant task
> > definition. As said, a clean build works fine.
>
> Could you try an ant build with the stack size set appropriately?
>
> > At the risk of sounding (even more) stupid: how do I get at the stack
> > trace?
>
> Where are you seeing that assertion? In the Error Log view?
>
> Cheers,
>
>
> Miles

Miles,

BTW, It iseems, I have missed something - how to force .scala_dependencies
creation for "old" projects? (remove/add Scala nature doesn't work for me).

On Thu, Oct 15, 2009 at 10:47 AM, Andrew Gaydenko wrote:
> BTW, It iseems, I have missed something - how to force .scala_dependencies
> creation for "old" projects? (remove/add Scala nature doesn't work for me).

The dependencies file will be created as a side-effect of building.

Cheers,

Miles

On Thursday 15 October 2009 13:58:04 you wrote:
> The dependencies file will be created as a side-effect of building.
>
> Cheers,
>
>
> Miles
>

I have tried to change a file and then Ctrl-S (as well as clean/build) -
nothing happens (r19100). Also have tried to add new Scala object, Ctrl-S -
again nothing compiled except for newly created object: .scala_dependencies
was created with the only newly created class item. As a result, ./bin
contains class files for the object and all my sources hierarchy tree without
class files (all empty tree).

On Thu, Oct 15, 2009 at 11:06 AM, Andrew Gaydenko wrote:
> I have tried to change a file and then Ctrl-S (as well as clean/build) -
> nothing happens (r19100). Also have tried to add new Scala object, Ctrl-S -
> again nothing compiled except for newly created object: .scala_dependencies
> was created with the only newly created class item.

Hmm ... yes, I'm also seeing this for newly created files. But
following a clean you should have a .scala_dependencies and from that
point on rebuilding of dependent files should happen on a save as
expected.

> As a result, ./bin contains class files for the object and all my sources
> hierarchy tree without class files (all empty tree).

Sorry, I can't parse that ... are you saying your *.scala files are
being copied to the output directory.

Cheers,

Miles

On Thursday 15 October 2009 14:25:26 you wrote:
> On Thu, Oct 15, 2009 at 11:06 AM, Andrew Gaydenko wrote:
> > I have tried to change a file and then Ctrl-S (as well as clean/build) -
> > nothing happens (r19100). Also have tried to add new Scala object, Ctrl-S
> > - again nothing compiled except for newly created object:
> > .scala_dependencies was created with the only newly created class item.
>
> Hmm ... yes, I'm also seeing this for newly created files. But
> following a clean you should have a .scala_dependencies and from that
> point on rebuilding of dependent files should happen on a save as
> expected.
>
> > As a result, ./bin contains class files for the object and all my sources
> > hierarchy tree without class files (all empty tree).
>
> Sorry, I can't parse that

(sorry, my English isn't perfect)

> ... are you saying your *.scala files are
> being copied to the output directory.

No .scala files, just tree of empty directories (in accordance with src tree)
in /bin + the only .class files created for this new object. All other ("old")
scala files were not compiled - probably because "nothing changed". As I have
said, clean/build doesn't help also.

On Thu, Oct 15, 2009 at 11:39 AM, Andrew Gaydenko wrote:
> No .scala files, just tree of empty directories (in accordance with src tree)
> in /bin + the only .class files created for this new object. All other ("old")
> scala files were not compiled - probably because "nothing changed". As I have
> said, clean/build doesn't help also.

OK, a clean build should help ... does this project compile correctly
using the command line tools?

Cheers,

Miles

On Thursday 15 October 2009 14:49:10 you wrote:
> On Thu, Oct 15, 2009 at 11:39 AM, Andrew Gaydenko wrote:
> > No .scala files, just tree of empty directories (in accordance with src
> > tree) in /bin + the only .class files created for this new object. All
> > other ("old") scala files were not compiled - probably because "nothing
> > changed". As I have said, clean/build doesn't help also.
>
> OK, a clean build should help ...

As I have said, it doesn't take place - clean build doesn't hook sources.

> does this project compile correctly
> using the command line tools?

Miles, yes, of course! - with own ant build file, inside NetBeans project -
any way you want :-)

Probably, I must clean something "old" somewhere?

On Thu, Oct 15, 2009 at 12:04 PM, Andrew Gaydenko wrote:
>> does this project compile correctly
>> using the command line tools?
>
> Miles, yes, of course! - with own ant build file, inside NetBeans project -
> any way you want :-)

The command line tools corresponding to the Eclipse build you're
working with? Ie. the nightly build of the same date?

Is there anything showing up in Eclipse's Error Log view when you do a
clean build?

> Probably, I must clean something "old" somewhere?

Can you send me the project ...

Cheers,

Miles

On Thursday 15 October 2009 15:11:47 Miles Sabin wrote:
> The command line tools corresponding to the Eclipse build you're
> working with? Ie. the nightly build of the same date?

Yes - both plugin and scala enviroment are r19100 from trunk. And, to be sure,
I have executed my ant script just now without any problems.

> Is there anything showing up in Eclipse's Error Log view when you do a
> clean build?

Yes! - the fragment is below.

> Can you send me the project ...

Sorry, it is closed yet.

//---------------------------------------------------------------

!ENTRY org.eclipse.core.resources 4 2 2009-10-15 15:26:39.392
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.core.resources".
!STACK 0
java.lang.NullPointerException
at scala.tools.nsc.typechecker.Typers$Typer.typedSelect$1(Typers.scala:3277)
at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3729)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3810)
at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3657)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3810)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3855)
at scala.tools.nsc.typechecker.SyntheticMethods$class.canEqualCheck$1(SyntheticMethods.scala:186)
at scala.tools.nsc.typechecker.SyntheticMethods$class.equalsClassMethod$1(SyntheticMethods.scala:198)
at scala.tools.nsc.typechecker.SyntheticMethods$$anonfun$classMethods$1$3.apply(SyntheticMethods.scala:248)
at scala.tools.nsc.typechecker.SyntheticMethods$$anonfun$classMethods$1$3.apply(SyntheticMethods.scala:248)
at scala.tools.nsc.typechecker.SyntheticMethods$$anonfun$addSyntheticMethods$3.apply(SyntheticMethods.scala:274)
at scala.tools.nsc.typechecker.SyntheticMethods$$anonfun$addSyntheticMethods$3.apply(SyntheticMethods.scala:273)
at scala.collection.LinearSeqLike$class.foreach(LinearSeqLike.scala:84)
at scala.collection.immutable.List.foreach(List.scala:29)
at scala.tools.nsc.typechecker.SyntheticMethods$class.addSyntheticMethods(SyntheticMethods.scala:273)
at scala.tools.nsc.Global$analyzer$.addSyntheticMethods(Global.scala:356)
at scala.tools.nsc.typechecker.Typers$Typer.typedClassDef(Typers.scala:1261)
at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3505)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3810)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3855)
at scala.tools.nsc.typechecker.Typers$Typer.typedStat$1(Typers.scala:1853)
at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$19.apply(Typers.scala:1912)
at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$19.apply(Typers.scala:1912)
at scala.collection.immutable.List.loop$2(List.scala:125)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.collection.immutable.List.loop$2(List.scala:129)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.tools.nsc.typechecker.Typers$Typer.typedStats(Typers.scala:1912)
at scala.tools.nsc.typechecker.Typers$Typer.typedTemplate(Typers.scala:1448)
at scala.tools.nsc.typechecker.Typers$Typer.typedClassDef(Typers.scala:1260)
at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3505)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3810)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3855)
at scala.tools.nsc.typechecker.Typers$Typer.typedStat$1(Typers.scala:1853)
at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$19.apply(Typers.scala:1912)
at scala.tools.nsc.typechecker.Typers$Typer$$anonfun$19.apply(Typers.scala:1912)
at scala.collection.immutable.List.loop$2(List.scala:125)
at scala.collection.immutable.List.mapConserve(List.scala:142)
at scala.tools.nsc.typechecker.Typers$Typer.typedStats(Typers.scala:1912)
at scala.tools.nsc.typechecker.Typers$Typer.typed1(Typers.scala:3501)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3810)
at scala.tools.nsc.typechecker.Typers$Typer.typed(Typers.scala:3855)
at scala.tools.nsc.typechecker.Analyzer$typerFactory$$anon$2.apply(Analyzer.scala:57)
at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:337)
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:536)
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:807)
at scala.tools.nsc.Global$Run.compileFiles(Global.scala:873)
at scala.tools.nsc.interactive.RefinedBuildManager.update(RefinedBuildManager.scala:91)
at scala.tools.nsc.interactive.RefinedBuildManager.update(RefinedBuildManager.scala:77)
at scala.tools.eclipse.ScalaProject.build(ScalaProject.scala:442)
at scala.tools.eclipse.ScalaBuilder.build(ScalaBuilder.scala:78)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:627)

On Thu, Oct 15, 2009 at 12:31 PM, Andrew Gaydenko wrote:
> Yes! - the fragment is below.

That's a failure in scalac. Do you have -Xchecknull enabled in Eclipse
but not on the command line?

Cheers,

Miles

On Thursday 15 October 2009 15:51:26 you wrote:
> That's a failure in scalac. Do you have -Xchecknull enabled in Eclipse
> but not on the command line?

You have catched it - thanks! After turning the flag off I have rebuilt the
project at last.

Miles Sabin wrote:
>
> Could you try an ant build with the stack size set appropriately?
>

I would be happy to but do not know how right now. I will look into the docs
for the scalac Ant task or is that the wrong place?

Miles Sabin wrote:
>
> Where are you seeing that assertion? In the Error Log view?
>

It is a Eclipse popup with "Problem occurred" in the title bar saying
"Building workspace has encountered a problem. Error occurred during the
build."

It show an "OK" and a "Details" button. Clicking that gives the error text a
posted earlier.

Gr. Silvio

On Thu, Oct 15, 2009 at 12:57 PM, Andrew Gaydenko wrote:
> On Thursday 15 October 2009 15:51:26 you wrote:
>> That's a failure in scalac. Do you have -Xchecknull enabled in Eclipse
>> but not on the command line?
>
> You have catched it - thanks! After turning the flag off I have rebuilt the
> project at last.

Cool ... could you open a Trac ticket against the compiler with a
reproducible test case for that.

Cheers,

Miles

On Thu, Oct 15, 2009 at 12:58 PM, Silvio Bierman
wrote:
> Miles Sabin wrote:
>> Could you try an ant build with the stack size set appropriately?
>
> I would be happy to but do not know how right now. I will look into the docs
> for the scalac Ant task or is that the wrong place?

If you're using the scalac (rather than scalafork) Ant task then you
need to set the stacksize for Ant itself. Set ANT_OPTS to something
like "-Xms512M -Xmx1024M -Xss1M -XX:MaxPermSize=128M".

>> Where are you seeing that assertion? In the Error Log view?
>>
>
> It is a Eclipse popup with "Problem occurred" in the title bar saying
> "Building workspace has encountered a problem. Error occurred during the
> build."
>
> It show an "OK" and a "Details" button. Clicking that gives the error text a
> posted earlier.

OK, navigate Window => Show View => Error Log and see if you can see
an entry which corresponds to that assertion.

Cheers,

Miles

On Thursday 15 October 2009 15:58:39 Miles Sabin wrote:
> Cool ... could you open a Trac ticket against the compiler with a
> reproducible test case for that.

I'll try, but can not promise - I already have an experience of reducing
300KB of code to 300 bytes (#2323) - it's indeed hard, mind-breaking and
time-consuming job :-)

On Thursday 15 October 2009 15:58:39 Miles Sabin wrote:
> > Cool ... could you open a Trac ticket against the compiler with a
> > reproducible test case for that.

Ok, have "invented" short test case:

http://lampsvn.epfl.ch/trac/scala/ticket/2467