Andreas Stefik wrote:
It looks like I missed a few posts on this topic from a few days ago (Thanks, Jim!)<snip> This does seem to cause confusion and perhaps I should write Wiki article on it. In general though, my general strategy is that I always do virtually nothing n the parser, which produces an AST; at most I build those symbol tables that can be built at this point (sometimes this is all symbols of course). But then perhaps unlike most, I always have a tree walker whose sole job is to check semantic rules and (and this is the key bit I think), which rewrites any rules and tokens it needs to. Then, assuming there is no need to walk the tree again for other reasons, a code generation walk does not checking, but just spits out code. This means my semantic checker knows it is doing rewrites of nodes of course. Because I am rewriting, all the rules are returning CommonTree nodes , within which you will find .tree (in $x.tree) when you need that. However, just because you are not rewriting the nodes, doesn't mean you cannot turn on rewriting anyway if doing auto-rewrite causes you no pain ;-). What this gives you is nodes for everything, including rules that just have a single token. Then you can use: /** * Create a message regarding a root node such as an _expression_, taking the start and end positions * from the tree node. * * @param m The type of message you want to create * @param ct The CommonToken that we are reporting against * @param args The parameters for the message we are raising */ public void logMsg(MessageDescriptor m, CommonTree ct, Object... args) { CommonToken st; CommonToken et; st = (CommonToken)(tokens.get(ct.getTokenStartIndex())); et = (CommonToken)(tokens.get(ct.getTokenStopIndex())); // Call the standard logger, using the information in the tokens // logMsg(m, st.getLine(), st.getCharPositionInLine(), st.getStartIndex(), et.getStopIndex(), args); } If you use some tiny walkers that do and don't use re-writing, and try referencing $entity, and $entity.tree, then look at the generated code, you will get the drift as you will see things like missing attribute on $entity. If you have: ^(x=XXXXX ..... then you need to reference $x to get a CommonTree But if you have ^(XXXX y=ruley Then you will need $y.tree Then look at what happens if you are and are not doing rewrites in your tree parser. Finally, if you can't be bothered looking at the generated code, just try $x and if you get "Missing attribute ...", then you need $x.tree. You will pick it up by osmosis :-) Now, if you add the method: /** * Create a message regarding a single token, taking the start and end positions * from the token. * * @param m The type of message you want to create * @param ct The CommonToken that we are reporting against * @param args The parameters for the message we are raising */ public void logMsg(MessageDescriptor m, Token ct, Object... args) { // Call the standard logger, using the information in the token // logMsg(m, ((CommonToken)ct).getLine(), ((CommonToken)ct).getCharPositionInLine(), ((CommonToken)ct).getStartIndex(), ((CommonToken)ct).getStopIndex(), args); } And the method: /** * Log a particular message into the message log (typically from syntax errors and so on) * * @param msgDesc The message we want to log * @param line The line that this message appertains to * @param colPos The column position in the line * @param startPos The start offset of the error * @param endPos The end offset of the error * @param args The arguments for formatting the message */ public void logMsg(MessageDescriptor msgDesc, int line, int colPos, int startPos, int endPos, Object... args) { // Instantiate the message // Message m = new Message(msgDesc, fileName, line, colPos, startPos, endPos, args); // Store in the vector // messages.add(m); // Count the servirty // switch (msgDesc.getSeverity()) { case ERROR: errorCount++; break; case WARNING: warningCount++; break; case FATAL: errorCount++; fatalCount++; break; // No default as Enum is type safe } } --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en -~----------~----~----~----~------~----~------~--~--- |
List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
