Does the compiler build with -Xexperimental

On Fri, Nov 4, 2011 at 9:36 AM, Jordi Salvat i Alabart
wrote:
> Hi,
>
> I'm running into a number of problems trying to build ("ant dist") trunk
> with -Xexperimental.
>
> Is this expected? Should I open bug reports for them?

I find people expect pretty different things. I expect it though,
which is a bad sign for anyone expecting anything else. We don't do
continuous testing under -Xexperimental.

I think it's because of overridable objects -- enabling them correctly results in the following error:
[scalacfork] /Users/adriaan/git/scala-dev/src/library/scala/xml/MetaData.scala:30: error: could not optimize @tailrec annotated method concatenate: it is neither private nor final so can be overridden
[scalacfork]   def concatenate(attribs: MetaData, new_tail: MetaData): MetaData =
[scalacfork]       ^
simply removing the @tailrec annotation should get you going I guess

On Fri, Nov 4, 2011 at 10:07 AM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Nov 4, 2011 at 9:36 AM, Jordi Salvat i Alabart
<jordi.salvat.i.alabart@gmail.com> wrote:
> Hi,
>
> I'm running into a number of problems trying to build ("ant dist") trunk
> with -Xexperimental.
>
> Is this expected? Should I open bug reports for them?

I find people expect pretty different things.  I expect it though,
which is a bad sign for anyone expecting anything else.  We don't do
continuous testing under -Xexperimental.

That warning is bogus, you can't override top level objects. I'll fix it.

This was the first one. When I fixed that one I ran into another...

test.suite:
  [partest] Compiling files that are expected to build

BUILD FAILED
/home/jordi/workspace/scala/build.xml:1564: java.lang.ClassFormatError: Illegal class modifiers in class scala/actors/scheduler/ResizableThreadPoolScheduler: 0x419
[stack dump follows]

My question is really whether I should report those as bugs or that would be causing more noise than benefit.

--
Salut,

Jordi.


2011/11/4 Adriaan Moors <adriaan.moors@epfl.ch>

I think it's because of overridable objects -- enabling them correctly results in the following error:
[scalacfork] /Users/adriaan/git/scala-dev/src/library/scala/xml/MetaData.scala:30: error: could not optimize @tailrec annotated method concatenate: it is neither private nor final so can be overridden
[scalacfork]   def concatenate(attribs: MetaData, new_tail: MetaData): MetaData =
[scalacfork]       ^
simply removing the @tailrec annotation should get you going I guess

On Fri, Nov 4, 2011 at 10:07 AM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Nov 4, 2011 at 9:36 AM, Jordi Salvat i Alabart
<jordi.salvat.i.alabart@gmail.com> wrote:
> Hi,
>
> I'm running into a number of problems trying to build ("ant dist") trunk
> with -Xexperimental.
>
> Is this expected? Should I open bug reports for them?

I find people expect pretty different things.  I expect it though,
which is a bad sign for anyone expecting anything else.  We don't do
continuous testing under -Xexperimental.

On Fri, Nov 4, 2011 at 6:54 PM, Jordi Salvat i Alabart
wrote:
> BUILD FAILED
> /home/jordi/workspace/scala/build.xml:1564: java.lang.ClassFormatError:
> Illegal class modifiers in class

Hmm, so far I can't reproduce that.

> My question is really whether I should report those as bugs or that would be
> causing more noise than benefit.

What a nice day it is when someone considers the question! Thanks for
that. There's no universal answer; it's true that sometimes it's not
so useful to open a ticket, but if in doubt, err on the side of the
ticket. In this case I'm definitely interested because a
ClassFormatError is never part of the plan.

2011/11/4 Paul Phillips <paulp@improving.org>

What a nice day it is when someone considers the question! Thanks for
that.

:-)
 

In this case I'm definitely interested because a
ClassFormatError is never part of the plan.

I seem to be in really murky waters: in trying to reproduce it I ran into two JVM SIGSEGVs while compiling before I got to see it. I'll try a couple more times and file that report.

--
Salut,

Jordi.

On Sat, Nov 5, 2011 at 2:15 AM, Jordi Salvat i Alabart
wrote:
> I seem to be in really murky waters: in trying to reproduce it I ran into
> two JVM SIGSEGVs while compiling before I got to see it. I'll try a couple
> more times and file that report.

I was able to reproduce it on osx lion with the usual jvm.