Aaron: have you done the patch submission paperwork with the FSF? (as per http://gcc.gnu.org/contribute.html#legal )
If so, is your work available somewhere? Thanks Dave On Mon, 2013-07-01 at 23:56 +0100, Aaron Gray wrote: > I started to do this starting with the C++ parser class'izing it but > no one was interested. > > On 1 July 2013 20:43, Joseph S. Myers <jos...@codesourcery.com> wrote: > > On Mon, 1 Jul 2013, David Malcolm wrote: > > > >> > As for accessing globals directly versus via APIs: yes, I suppose you do > >> > still have an access to a global class instance in each place you > >> > formerly > >> > had a global variable (that's now a member of that class), so by itself > >> > such a conversion to a better API doesn't reduce the number of global > >> > variable accesses, just improves the interface in other ways - and it's > >> > the changes to pass a pointer to an instance around that reduce the > >> > global > >> > state usage. In the case of dump files, pass-local state may be a better > >> > place than the universe to keep the instance - it is after all passes.c > >> > that calls dump_start / dump_finish. > >> > >> So a pass instance should have its own dump_flags, and various dump > >> methods? Perhaps, but as before, I'd prefer to fix the state issue > > > > Yes (or rather, the pass instance should contain an instance of the dumper > > class, which in turn has dump_flags and dump_file members) - as far as I > > can tell, the lifetime of dump_file and dump_flags is already basically > > per-pass rather than global. > > > >> Would you be in favor killing off these macros: > >> #define input_line LOCATION_LINE (input_location) > >> #define input_filename LOCATION_FILE (input_location) > >> #define in_system_header (in_system_header_at (input_location)) > >> with patches that make the usage of "input_location" explicit? (by > >> replacing all uses of these macros with their expansions, cleaning up > >> line-wraps as needed). > > > > Yes. > > > >> The only other macro that implicitly uses input_location is > >> EXPR_LOC_OR_HERE; that could be removed in favor of: > >> EXPR_LOC_OR_LOC(expr, input_location) > >> again making input_location explicit. > > > > (I suspect then eliminating the input_location from this - ensuring all > > expressions have meaningful locations so EXPR_LOC_OR_LOC isn't needed at > > all - will depend on Andrew MacLeod's proposal. It doesn't explicitly > > mention this, but one thing that would be desirable as part of making > > front ends generate internal representation closer to the source would be > > explicitly representing locations for constants, and for references to > > declarations within expressions, so that everywhere that wants a location > > for an expression can reliably extract one from it rather than finding > > there is no location because certain expressions are shared.)
