[antlr-interest] Unnecessary Java output file diffs
Terence Parr
parrt at cs.usfca.edu
Wed May 20 12:13:34 PDT 2009
All you have to do is alter the line in Java.stg template file. We
could add an action variable like @members that fills in the version
template string.
Ter
On May 20, 2009, at 12:11 PM, Sam Harwell wrote:
> I wanted to make an option that doesn’t include the timestamp and
> line number in the generated file, but I couldn’t think of a name
> for it. Anyone have any suggestions?
>
> Sam
>
> From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-bounces at antlr.org
> ] On Behalf Of Tom Ball
> Sent: Wednesday, May 20, 2009 2:07 PM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] Unnecessary Java output file diffs
>
> Our distributed build system compares output files and only copies
> back the ones that have changed since the last build. We've noticed
> that our Antlr->Java step always gets copied, for two reasons.
> First, because a timestamp is in the output file's header -- is that
> necessary as a default? More useful might be a timestamp variable
> that can be put a .g file if desired, and expanded during generation.
>
> We think the second reason might be a bug, as here is some example
> output from a common, unchanged source file:
>
> @@ -2531,7 +2531,7 @@
> int index13_13 = input.index();
> input.rewind();
> s = -1;
> - if ( (((input.LT(1).getText()
> .equals("gte"))||(input.LT(1).getText().equals("lte"))||
> (input.LT(1).getText().equals("gt"))||
> (input.LT(1).getText().equals("lt"))||
> (input.LT(1).getText().equals("eq"))||
> (input.LT(1).getText().equals("ne")))) ) {s = 2;}
> + if
> ( (((input.LT(1).getText().equals("gte"))||
> (input.LT(1).getText().equals("lte"))||
> (input.LT(1).getText().equals("lt"))||
> (input.LT(1).getText().equals("gt"))||
> (input.LT(1).getText().equals("eq"))||
> (input.LT(1).getText().equals("ne")))) ) {s = 2;}
>
> else if ( (true) ) {s = 8;}
>
> Shouldn't the order of the token comparisons be the same for every
> generation? I guess it doesn't matter in this example since the
> string can only have one match, but my hunch is that with other
> rules comparison order matters. Here is the rule which generated
> the above:
>
> comparator returns [Operation value]
> : ((eqToken | '=') { $value = Operation.EQ; })
> | ((neToken | '!=') { $value = Operation.NEQ; })
> | ((gtToken | '>') { $value = Operation.GT; })
> | ((gteToken | '>=') { $value = Operation.GTE; })
> | ((ltToken | '<') { $value = Operation.LT; })
> | ((lteToken | '<=') { $value = Operation.LTE; })
> ;
>
> // Pseudo-tokens
> eqToken : {input.LT(1).getText().equals("eq")}? NCNAME ;
> neToken : {input.LT(1).getText().equals("ne")}? NCNAME ;
> ltToken : {input.LT(1).getText().equals("lt")}? NCNAME ;
> lteToken : {input.LT(1).getText().equals("lte")}? NCNAME ;
> gtToken : {input.LT(1).getText().equals("gt")}? NCNAME ;
> gteToken : {input.LT(1).getText().equals("gte")}? NCNAME ;
>
> NCNAME
> : (LETTER | '_') (LETTER | NONLETTER | '.' | '-' | '_')*
> ;
>
> Tom
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
More information about the antlr-interest
mailing list