Kay Röpke - 16/Jun/07 05:43 AM A patch that fixes this behavior is: ==== //depot/code/antlr/main/src/org/antlr/tool/antlr.g#81 - /Users/kroepke/Projects/antlr3/code/antlr/main/src/org/antlr/tool/antlr.g ==== @@ -1087,7 +1087,8 @@  NESTED_ARG_ACTION :         '['!         ( - NESTED_ARG_ACTION + "[]" + | NESTED_ARG_ACTION         | '\r' '\n' {newline();}         | '\n' {newline();}         | ACTION_STRING_LITERAL However, this might break other things, so I'm not sure if it is correct. Needs discussion. After applying the patch, you must rebuild the ANTLR grammars and recompile.

Kunle Odutola - 16/Jun/07 06:42 AM The method signature might be [,] or even [][] for some other language. We should just suport escaping the ']' character inside an 'argumentAction' block and we drop the leading escape char (using ! suffix notation). protected NESTED_ARG_ACTION :      '['!      ( NESTED_ARG_ACTION      | '\r' '\n' {newline();}      | '\n' {newline();}      | '\\'! ']' // <--- our new rule      | ACTION_STRING_LITERAL      | ~']'      )*      ']'!     ; The sample grammar in your JIRA issue is then:           grammar Test;           start[String[\] strArr]           : 'TEST'           ; NOTE: This might result in non-determinism conflicts with ACTION_ESC that can be easily solved. (I think)

Kay Röpke - 16/Jun/07 11:36 AM The above patch doesn't work, because the leading '[' is eaten by the recursive NESTED_ARG_ACTION invocation and it eventually barfs. Changing the rule to: protected NESTED_ARG_ACTION : '['! ( NESTED_ARG_ACTION | '\r' '\n' {newline();} | '\n' {newline();} | '\\'! ('['|']') | ACTION_STRING_LITERAL | ~']' )* ']'! ; does the trick. It has the added benefit that the escaping must be done on both the opening and closing brackets, which makes a lot more sense to me as a programmer. I'll check with Ter and then I'll push this change.

Kunle Odutola - 16/Jun/07 05:59 PM This is only an issue because the enclosing '[' and ']' characters are excluded (using ! operator) from the NESTED_ARG_ACTION token "fragment". Actually, why is that?. I can't see any benefit to removing enclosing brackets from *nested* actions. Would it suffice to accept all and simply remove the outermost '[' and ']' in ARG_ACTION once an entire token char sequence has been matched. That would remove this issue entirely. Something like this (untested) snippet: ARG_ACTION    : '['! NESTED_ARG_ACTION ']'! ; protected NESTED_ARG_ACTION : ( '[' NESTED_ARG_ACTION ']' | '\r' '\n' {newline();} | '\n' {newline();} | ACTION_STRING_LITERAL | ~']' )* ;

Kay Röpke - 17/Jun/07 09:22 AM Yes, true enough. Interestingly the issue is only with "declarative ARG_ACTIONS", i.e. rule arguments, return values, and catch clauses (although those shouldn't require any brackets, at least in no language I know about). The nesting stuff is only necessary for calling rules, right? Maybe it would be easier to have separate rules for declarations and rule invocations, thus removing all these issues. On the other hand, it may be futile work, because once the transition to v3 grammars comes around, much of this work will be obsolete anyway. I don't really care if we only allow balanced brackets, or require escaping. The only downside right now is that this type of thing doesn't work at all, which is a bummer.

Kay Röpke - 02/Aug/07 04:52 PM a similar problem exists with Java generics: On Aug 1, 2007, at 6:34 PM, Manju Shekhar wrote:   services_r returns [HashMap<String, Service> svcs]          @init { $svcs = new HashMap<String, Service>(); }          :          ^( SERVICES (s=service_r)+ )          ;   However the above generates the following snippet of java code:   public static class services_r_return extends TreeRuleReturnScope {          public HashMap<String;          public Service> svcs;          public StringTemplate st;          public Object getTemplate() { return st; }          public String toString()          { return st==null?null:st.toString(); }  };

Terence Parr - 27/Dec/07 01:27 PM Altered antlr.g to suit. Must escape \\].