GitLab

libcpp/

	* include/line-map.h (struct linemap_stats): Change the type of
	the members from size_t to long.
	* macro.c (macro_arg_token_iter_init): Unconditionally initialize
	iter->location_ptr.

gcc/c-family/

	* c-lex.c (fe_file_change): Use LINEMAP_SYSP when
	!NO_IMPLICIT_EXTERN_C.

gcc/
	* input.c (dump_line_table_statistics): Use long, not size_t.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180124 138bc75d-0d04-0410-961f-82ee72b054a4

This patch adds statistics about line maps' memory consumption and
macro expansion to the output of -fmem-report.  It has been useful in
trying to reduce the memory consumption of the macro maps support.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180085 138bc75d-0d04-0410-961f-82ee72b054a4

This second instalment uses the infrastructure of the previous patch
to allocate a macro map for each macro expansion and assign a virtual
location to each token resulting from the expansion.

To date when cpp_get_token comes across a token that happens to be a
macro, the macro expander kicks in, expands the macro, pushes the
resulting tokens onto a "token context" and returns a dummy padding
token. The next call to cpp_get_token goes look into the token context
for the next token [which is going to result from the previous macro
expansion] and returns it.  If the token is a macro, the macro expander
kicks in and you know the story.

This patch piggy-backs on that macro expansion process, so to speak.
First it modifies the macro expander to make it create a macro map for
each macro expansion. It then allocates a virtual location for each
resulting token.  Virtual locations of tokens resulting from macro
expansions are then stored on a special kind of context called an...

This is the first instalment of a set which goal is to track locations
of tokens across macro expansions.  Tom Tromey did the original work
and attached the patch to PR preprocessor/7263.  This opus is a
derivative of that original work.

This patch modifies the linemap module of libcpp to add virtual
locations support.

A virtual location is a mapped location that can resolve to several
different physical locations.  It can always resolve to the spelling
location of a token.  For tokens resulting from macro expansion it can
resolve to:
  - either the location of the expansion point of the macro.
  - or the location of the token in the definition of the
  macro
  - or, if the token is an argument of a function-like macro,
  the location of the use of the matching macro parameter in
  the definition of the macro

The patch creates a new type of line map called a macro map.  For every
single macro expansion, there is a macro map that generates a virtual
location for every single resulting token of the expansion.

The good old type of line map we all know is now called an ordinary
map.  That one still encodes spelling locations as it has always had.

As a result linemap_lookup as been extended to return a macro map when
given a virtual location resulting from a macro expansion.  The layout
of structs line_map has changed to support this new type of map.  So
did the layout of struct line_maps.  Accessor macros have been
introduced to avoid messing with the implementation details of these
datastructures directly.  This helped already as we have been testing
different ways of arranging these datastructure.  Having to constantly
adjust client code that is too tied with the internals of line_map and
line_maps would have been even more painful.

Of course, many new public functions have been added to the linemap
module to handle the resolution of virtual locations.

This patch introduces the infrastructure but no part of the compiler
uses virtual locations yet.

However the client code of the linemap data structures has been
adjusted as per the changes.  E.g, it's not anymore reliable for a
client code to manipulate struct line_map directly if it just wants to
deal with spelling locations, because struct line_map can now
represent a macro map as well.  In that case, it's better to use the
convenient API to resolve the initial (possibly virtual) location to a
spelling location (or to an ordinary map) and use that.

This is the reason why the patch adjusts the Java, Ada and Fortran
front ends.

Also, note that virtual locations are not supposed to be ordered for
relations '<' and '>' anymore.  To test if a virtual location appears
"before" another one, one has to use a new operator exposed by the
line map interface.  The patch updates the only spot (in the
diagnostics module) I have found that was making the assumption that
locations were ordered for these relations.  This is the only change
that introduces a use of the new line map API in this patch, so I am
adding a regression test for it only.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180081 138bc75d-0d04-0410-961f-82ee72b054a4

	* input.h (main_input_filename): Move declaration to toplev.h.
	* toplev.c (input_location, line_table): Move to input.c
	* toplev.h (main_input_filename): Move declaration from input.h.
	* tree.c (expand_location): Move to input.c.
	* Makefile.in (OBJS-common): Add input.o.
	(input.o): Add dependencies.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@159914 138bc75d-0d04-0410-961f-82ee72b054a4