This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Quoting In Error/Warning Messages for Java
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: jsm at polyomino dot org dot uk, GCJ <java at gcc dot gnu dot org>
- Date: Sun, 19 Sep 2004 08:55:28 +0530
- Subject: Re: Quoting In Error/Warning Messages for Java
- References: <39399b9d040918040610097ca3@mail.gmail.com> <414C5BF1.9030705@bothner.com>
- Reply-to: Ranjit Mathew <rmathew at gmail dot com>
On Sat, 18 Sep 2004 09:01:53 -0700, Per Bothner <per@bothner.com> wrote:
> Ranjit Mathew wrote:
>
> > I found that most of the errors were being issued via
> > parse_error_context( ) which (like parse_warning_context) uses
> > issue_warning_error_from_context( ) (all defined in parse.y)
> > which directly uses vsprintf() to create the message.
>
> The reason for that is probably to be able to emit "caret" diagnostics:
> error messages including column numbers and echoing the
> erroneous line. Hopefully soon the USE_MAPPED_LOCATION patch
> will be in, which will remove/reduce the need for the special
> error handling.
Ok.
> > For the rest, shall I just use 'foo' style quoting instead of
> > `foo'?
>
> How about for now using %<...%> and writing a 5-line patch to
> convert %<...%> to '...'. Then we can use the new %<...%>
> immediately.
That's what I tried next. However, parse_error_context()
is marked ATTRIBUTE_PRINTF in java-tree.h and the
bootstrapping compiler warns (and therefore errors
out due to -Werror) about unknown format specifiers
'%<' and '%>'. So I had to mark them
ATTRIBUTE_GCC_FE_DIAG(2,3) which is defined in
"toplev.h" - this leads to the requirement that
"toplev.h" be included before "java-tree.h" everywhere.
So I had to touch almost every source file to correct
this...
...including gjavah, which defines its own "error()"
function which clashes with that in "toplev.h" and
so I had to correct that...
Alternatively, I can just define the appropriate
attribute in-situ in "java-tree.h", but that will not be
clean enough...
In short, IMHO, it becomes too intrusive at this
stage.
My options:
1. Wait for your "--enable-mapped-location" patch
which probably can be made default (and the only
thingy) for GCJ.
2. Just use 'foo' style blindly everywhere...
What do you suggest?
BTW, if your "--enable-mapped-location" patch
gets in, will we get rid of all WFLs and EWFLs?
That would be cool because I could never grok
them completely.
Thanks,
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.tripod.com/