[antlr-interest] Re: Get the line number in my deprecated messages

[Ric Klaren]

On Wed, Jun 02, 2004 at 12:40:40PM -0000, pwolleba wrote:
> As far I can see the getLine method is inside the CharScanner class,
> I can however not see any solution for reaching this class from my
> parser class.
>
> If there is someone, reading this newsgroup, that has implemented a
> deprecated message in their parsers I would be really happy if you
> could send me an example on how you did it.
> I have so far not found 1 single example that demonstrates this
> problem.

Notice the reportWarning and reportError methods in the
Parser/Lexer/Treewalker classes. You can override these with custom ones
(if you want to). These are used by the antlr generated code print errors
and warnings. Override these to get custom behaviour. You can also call
them directly to print messages.

Personally I add also a few reportError/Warning methods with signatures
like the following:

/** Report warning near location indicated by tok */
void reportWarning( antlr::RefToken tok, const std::string& s );
/** Report warning near location indicated by ast */
void reportWarning( RefModest_AST ast, const std::string& s );

(translating C++ to java left to the reader)

It can be convenient to have line information in your (custom) AST. And the
latter reportWarning only makes sense if you have it.

The best ways to get line information is to get it directly from labeled
tokens or pieces of AST. This is always correct in it's location if all
else fails you can abuse LT(1) in the parser to get the line information
from. ( LT(1).getLine() )

Things are easiest when you got access to the Tokens or pieces of AST (in
the parser even if you're using treebuilding).

Now to your question.

You can basically just put a reportWarning/Error in the action code for the
constructs that are deprecated in the case of serious errors you can also
throw a SemanticException (see the java file for the signature of the
beast). Throwing an exception may be inadequate depending on your error
handler settings.

So to make a long story short:

Suppose we have a language that defines functions at one time using:

void x(x) char *x; { /* body */ }

But now we use good old ansi style:

void x( char* x ) { /* body */ }

function:
   ast:type tok:ID "("
   ( id_list ")" parameter_type_list
      {
         // if you're using ast's with line numbers and have a
         // reportWarning as above
         reportWarning( #ast, "Old style function declaration" );
         // don't have fancy ast's? use a token in the vicinity
         reportWarning( tok, "Old style function declaration" );
      }
   | parameter_list ")"
   )
   body
;

The AST strategy only works with buildAST is true in the parser (or if you
build it yourself manually). It also has some more caveat's with respect to
custom errorhandlers or the absence thereof (you may have to check for
nullAST's due to syntax errors in the input)

Depending on the structure of your grammar it may be easier or more
difficult to give warnings in the right spot. But the general idea is the
same as with 'normal' warnings/errors.

Cheers,

Ric
--
-----+++++*****************************************************+++++++++-------
    ---- Ric Klaren ----- j.klaren at utwente.nl ----- +31 53 4893755  ----
-----+++++*****************************************************+++++++++-------
     "Never argue with an idiot, for they will bring you down to their
              level and beat you with experience." --- Unknown



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/