Re: [patch request] don't run ecj on auto generated files

[Andrew Cagney <cagney at redhat dot com>]

Stan,

I'm not personally warming to the idea for a number of reasons: one of 
the key reasons for putting the code through ECJ is that that compiler 
detects bad source that GCJ will accept and turn into bad code - even 
generated files are exposed to this risk; very shortly GCJ will switch 
to ECJ as it's front end and we'll be right back where we started; and 
too often a warning, even in generated code, indicates that there is a 
problem, even if it is with the generator (the other generated files 
don't have problems right?).

Since antlr is the real concern, can something more local be done?  For 
instance,  is there a newer antlr and is it any better?  Or can the 
antlr warnings be handled another way?  Howe aware is upstream of the 
issues?

Andrew
> antlr generates files which generate warnings from ecj, for example 
> unreferenced variables.  The current strategy is to use sed scripts to 
> postprocess the sources.  However, this is error prone and requires 
> constant tweaking.  Are there any objections to only running ecj on 
> top_srcdir *.java files and not running ecj on top_builddir *.java 
> files?  I think this change would mostly effect antlr (Cpp*), but here 
> is the entire list of autogenerated files:
> AT.java                 ELF.java                SHF.java
> Build.java              EM.java                 SHN.java
> Config.java             ET.java                 SHT.java
> CppLexer.java           EV.java                 Sig.java
> CppParser.java          JUnitTests.java         STB.java
> CppParserTokenTypes.jav NT.java                 STT.java
> CppTreeParser.java      PF.java                 STV.java
> CppTreeParserTokenTypes PowerPC.java            SyscallNum.java
> DW.java                 PT.java                 TestRunner.java
> EI.java