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.) > > -- > Joseph S. Myers > jos...@codesourcery.com
