[gcjx] RFC/RFA: Show Problematic Source Lines with Diagnostics

[Ranjit Mathew]

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

Hi,

  As noted earlier, GCJX doesn't show the problematic lines from
Java source files with its diagnostics, unlike most compilers. The
attached patch proposes to fix this situation.

The first order of business was to be able to retrieve a line
from a source file given its line number, since the current
lexer just works with a stream of tokens. I have opted to
just rewind and read the desired line, instead of storing
line number information upfront as I reckon the compiler will
encounter *far more* correct source files in real life every
time than incorrect source code - there's no point in penalising
the common code path for this feature. Besides this, GCJ mainline
also does a similar thing.

That aside, I wanted the lexer to be able to retrieve the
desired line and get back to its previous state. This might
not matter now, since we just lex the whole file at once. This
is the reason for the new positioning methods in ucs2_reader,
though it does hurt the abstraction a bit - it becomes a
random-access across the input instead of a linear stream of
bytes.

Next up was for the exception formatter to be able to
show the desired line with a little caret underneath the
problematic column, for which it needed access to the lexer.
This is the reason for the new set_lexer methods in exception_base
and format_repr.

Since lines would be needed after the whole file has been parsed,
it was no longer proper to ditch the lexer after the parsing
phase. Hence I moved the ownership of the lexer from the parse
class to the compiler class.

The effect of this patch is shown below:
- --------------------------- 8< ---------------------------
~/src/GCJ > cat Hello.java
public class Hello
{
  public static void main( String[] args)
  {
    junk foo;
    System.out.println( "Hello World!");
  }
}
~/src/GCJ > $GCJX Hello.java
./Hello.java:6:4: error: type named 'junk' is undefined

    System.out.println( "Hello World!");
    ^

- --------------------------- 8< ---------------------------

Note that the wrong line and column is shown here. But that's
not my fault - the incoming information was wrong to begin
with! That's material for another patch, another day.

Tested on i686-pc-linux-gnu. No changes in Jacks.

OK? Comments?

Thanks,
Ranjit.

- --
Ranjit Mathew       Email: rmathew AT gmail DOT com

Bangalore, INDIA.     Web: http://ranjitmathew.hostingzero.com/




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDQAloYb1hx2wRS48RAlSPAKCDKG+p8rWFyh6zu1w77K/wnw1Y7QCfUsFX
/uQxaJbzWBO7ambiXs+6l30=
=BA0O
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: t1.txt
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20051002/562a672f/attachment.txt>