four items, neatly numbered

Paul Phillips wrote:
> Seeking a little feedback if anyone has a moment:
>
> 1) If there are no objections I will commit the patch making the second arg to assert and friends by-name
> (I won't commit anything until trunk builds again though.)
>

I agree with that. However, it would be nice to make it configurable,
similarly to the way javac does. Something like this:

val assertionsEnabled = getClass().desiredAssertionStatus()

@inline
def assert1(prop: => Boolean, msg: => Any): Unit = {
if (assertionsEnabled && !prop)
throw new java.lang.AssertionError(msg)
}

Granted, this will take into account the assertion status for Predef
instead of the caller, and won't be configurable on a per-class basis. I
think that's acceptable. Tests I did a while ago showed that this method
is extremely slow, that's why the result is cached in a field (that's
what javac does as well, in the class constructor).

The @inline annotation is useful because it makes the inliner happier
abount inlining it (keeps its cost zero, when deciding whether it's
worth to inline it or not).

> 4) As a guy who has recently gone through almost every open ticket, I can testify that #333333 would be very
> helpful:
>
> https://lampsvn.epfl.ch/trac/scala/ticket/426
> ("Adding compiler version to compiler exception")
>
> ...but I can't figure out a clean way to do this without undertaking a significant effort to unify the
> compiler's error handling, and if I was to undertake that it'd be criminal not to better unify logging as
> well. (Speaking of logging, the new -Xprint:all option comes highly recommended for seeing what's going on in
> there.) Do people have opinions about this they'd like to share?
>
Is it really worth the effort? It's so easy to type scalac -version
after a crash and get the version. I'm not sure how you plan to add a
version to all crashes, maybe by a big catch all in Global? I'm thinking
of MatchError and NPEs. I never found that a huge problem in bug reports
either... we need to reproduce it anyway, and if it works in trunk the
bug report is discarded (usually.. now we have a 2.7 branch we continue
to support, but that's not a model we'll sustain for long).

> I'll stop for now, I know everyone is plenty busy with their own projects. I greatly appreciate the level of
> autonomy I've been given and for the most part I'm more than happy to rely on my own judgment, but when
> decisions might have consequences beyond the immediately surrounding code I try for a second opinion. (On the
> other hand, there's always "revert".)
>
We're all here very happy to have you working on this project! I think
your questions make a lot of sense and your policy of asking people's
opinion before breaking changes is appreciated.

Cheers,
iulian

On Fri, Feb 13, 2009 at 07:36:09PM +0100, Iulian Dragos wrote:
> I agree with that. However, it would be nice to make it configurable,
> similarly to the way javac does.

I'll explore that, I've not looked at javac much.

> @inline

Oh that's interesting, I didn't know that was in play. It doesn't look like that annotation is used anywhere
in the compiler, but maybe the compiler figures it knows itself well enough already.

> Is it really worth the effort? It's so easy to type scalac -version after
> a crash and get the version.

It's easy for us, it's the people who just cut and paste a stack trace I'm thinking of. In an effort to
maintain good records I'm trying to isolate in exactly which version any given bug was fixed, which would be
speedier if I knew when the stack trace was from; I've found open bugs that have been fixed since 2.6.1 (and
earlier I'm sure but that's as far back as I check.) And you're right, it's not worth effort by itself, but a
well-defined error resolution path for the compiler is appealing for all sorts of reasons. The bugs I'm
examining are getting thornier and increasingly I pine for a simple mechanism to turn on/off tracing,
increase/decrease output, cause faster failing when some condition under investigation comes true, etc. etc.