script positions

Maybe Lex could have a look at this. I think he was the one who originally made scripts work.

Cheers

 -- Martin

On Thu, May 13, 2010 at 9:10 PM, Paul Phillips <paulp@improving.org> wrote:

I'm not sure what possessed me to blow a whole morning on something as
tedious as script positions the day after I promised to start ignoring
trunk to work on the pattern matcher.  But so it goes.

Can I get an opinion on this patch? I don't want to mess with something
as delicate as positions without an upward or at least sideways pointing
thumb.

http://github.com/paulp/scala/commit/f27530379a279a4952d102e697c60663fa28b7a6

I'm not ecstatic about it but I think it's good enough.  I had to add
infrastructure.  As you look at the below and think to yourself that
said infrastructure belongs at some higher level, chastise yourself for
thinking that because thanks to fsc and "-Xscript", scripts may be
assembled from fragments in two utterly different places (one is inside
the compiler and one is outside it for starters.) It was this, or tear
apart even more stuff trying for common fragment assembling machinery.


To Reporter: def ignoreIf(f: Position => Boolean) sets a suppression
function so any errors/warnings/whatever for which that function returns
true are completely ignored.

To SourceFile: def isSynthetic: Boolean

To CompoundSourceFile: def componentIsSynthetic(pos: Position)


With all that in hand, we can tackle #3170 with ambition well beyond the
misnumbering being reported:

 http://lampsvn.epfl.ch/trac/scala/ticket/3170
 "Line numbers wrong in script compiler errors"

Here is A.scala from that ticket:

#! scala
!#

val x = "line 4"
val y = "line 5"
val z "line 6"

Here is the current output from running that script:

% scala28 A.scala
(fragment of A.scala):3: error: '=' expected but string literal found.
val y = "line 5"
           ^
(fragment of A.scala):4: error: illegal start of simple expression
val z "line 6"
          ^
two errors found


Not so good.  2.7 is slightly more accurate but even noisier.

% scala27 A.scala
(fragment of A.scala):4: error: '=' expected but string literal found.
val z "line 6"
      ^
(virtual file):1: error: illegal start of simple expression
object Main {
  ^
two errors found
!!!
discarding <script preamble>
!!!
discarding <script preamble>
discarding (fragment of A.scala)



Here it is after my patch.

% scala A.scala
/scala/trac/3170/A.scala:6: error: '=' expected but string literal found.
val z "line 6"
     ^
one error found

Or the other code path:

% scala -nocompdaemon A.scala
A.scala:6: error: '=' expected but string literal found.
val z "line 6"
     ^

A ha, we don't need to hear about spurious errors which the compiler
traces back to the wrapper.  The positions you need and only the
positions you need, here at Clean Error Messages Corp.

--
Paul Phillips      | We act as though comfort and luxury were the chief
Future Perfect     | requirements of life, when all that we need to make us
Empiricist         | really happy is something to be enthusiastic about.
ha! spill, pupil   |     -- Charles Kingsley

On Thu, May 13, 2010 at 8:10 PM, Paul Phillips wrote:
> Can I get an opinion on this patch? I don't want to mess with something
> as delicate as positions without an upward or at least sideways pointing
> thumb.

I can't see anything here which looks like it would obviously hose
IDEs which are depending on positions.

I'd appreciate it if you'd verify that the ant test.positions target
completes successfully before committing (tho' again, I can't see
anything obvious in your patch which would affect that).

Cheers,

Miles

>>>>> "Paul" == Paul Phillips writes:

Paul> I'm not sure what possessed me to blow a whole morning on
Paul> something as tedious as script positions the day after I promised
Paul> to start ignoring trunk to work on the pattern matcher. But so
Paul> it goes.

Paul> Can I get an opinion on this patch? I don't want to mess with
Paul> something as delicate as positions without an upward or at least
Paul> sideways pointing thumb.

I can't comment on the code, but I'm really glad you're working on this
because despite the unsexiness of the issue, I think it actually makes a
big difference in the usability of Scala for scripting tasks and in the
impression that Scala makes on new users.