2001-08-03 01:03:31 +02:00
|
|
|
/* Map logical line numbers to (source file, line number) pairs.
|
2014-01-02 23:24:45 +01:00
|
|
|
Copyright (C) 2001-2014 Free Software Foundation, Inc.
|
2001-08-03 01:03:31 +02:00
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify it
|
|
|
|
under the terms of the GNU General Public License as published by the
|
2009-04-09 17:00:19 +02:00
|
|
|
Free Software Foundation; either version 3, or (at your option) any
|
2001-08-03 01:03:31 +02:00
|
|
|
later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
2009-04-09 17:00:19 +02:00
|
|
|
along with this program; see the file COPYING3. If not see
|
|
|
|
<http://www.gnu.org/licenses/>.
|
2001-08-03 01:03:31 +02:00
|
|
|
|
|
|
|
In other words, you are welcome to use, share and improve this program.
|
|
|
|
You are forbidden to forbid anyone else to use, share and improve
|
|
|
|
what you give them. Help stamp out software-hoarding! */
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
#include "system.h"
|
|
|
|
#include "line-map.h"
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
#include "cpplib.h"
|
|
|
|
#include "internal.h"
|
2012-09-19 21:56:42 +02:00
|
|
|
#include "hashtab.h"
|
2001-08-03 01:03:31 +02:00
|
|
|
|
2003-06-20 07:51:13 +02:00
|
|
|
static void trace_include (const struct line_maps *, const struct line_map *);
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
static const struct line_map * linemap_ordinary_map_lookup (struct line_maps *,
|
|
|
|
source_location);
|
|
|
|
static const struct line_map* linemap_macro_map_lookup (struct line_maps *,
|
|
|
|
source_location);
|
|
|
|
static source_location linemap_macro_map_loc_to_def_point
|
|
|
|
(const struct line_map*, source_location);
|
|
|
|
static source_location linemap_macro_map_loc_unwind_toward_spelling
|
|
|
|
(const struct line_map*, source_location);
|
|
|
|
static source_location linemap_macro_map_loc_to_exp_point
|
|
|
|
(const struct line_map*, source_location);
|
|
|
|
static source_location linemap_macro_loc_to_spelling_point
|
|
|
|
(struct line_maps *, source_location, const struct line_map **);
|
|
|
|
static source_location linemap_macro_loc_to_def_point (struct line_maps *,
|
|
|
|
source_location,
|
|
|
|
const struct line_map **);
|
|
|
|
static source_location linemap_macro_loc_to_exp_point (struct line_maps *,
|
|
|
|
source_location,
|
|
|
|
const struct line_map **);
|
2001-08-21 23:17:48 +02:00
|
|
|
|
2011-10-17 11:59:52 +02:00
|
|
|
/* Counters defined in macro.c. */
|
|
|
|
extern unsigned num_expanded_macros_counter;
|
|
|
|
extern unsigned num_macro_tokens_counter;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
/* Hash function for location_adhoc_data hashtable. */
|
|
|
|
|
|
|
|
static hashval_t
|
|
|
|
location_adhoc_data_hash (const void *l)
|
|
|
|
{
|
|
|
|
const struct location_adhoc_data *lb =
|
|
|
|
(const struct location_adhoc_data *) l;
|
2012-09-25 23:32:29 +02:00
|
|
|
return (hashval_t) lb->locus + (size_t) lb->data;
|
2012-09-19 21:56:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Compare function for location_adhoc_data hashtable. */
|
|
|
|
|
|
|
|
static int
|
|
|
|
location_adhoc_data_eq (const void *l1, const void *l2)
|
|
|
|
{
|
|
|
|
const struct location_adhoc_data *lb1 =
|
|
|
|
(const struct location_adhoc_data *) l1;
|
|
|
|
const struct location_adhoc_data *lb2 =
|
|
|
|
(const struct location_adhoc_data *) l2;
|
|
|
|
return lb1->locus == lb2->locus && lb1->data == lb2->data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Update the hashtable when location_adhoc_data is reallocated. */
|
|
|
|
|
|
|
|
static int
|
|
|
|
location_adhoc_data_update (void **slot, void *data)
|
|
|
|
{
|
|
|
|
*((char **) slot) += *((long long *) data);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2012-09-25 15:19:33 +02:00
|
|
|
/* Rebuild the hash table from the location adhoc data. */
|
|
|
|
|
|
|
|
void
|
|
|
|
rebuild_location_adhoc_htab (struct line_maps *set)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
set->location_adhoc_data_map.htab =
|
|
|
|
htab_create (100, location_adhoc_data_hash, location_adhoc_data_eq, NULL);
|
|
|
|
for (i = 0; i < set->location_adhoc_data_map.curr_loc; i++)
|
|
|
|
htab_find_slot (set->location_adhoc_data_map.htab,
|
|
|
|
set->location_adhoc_data_map.data + i, INSERT);
|
|
|
|
}
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
/* Combine LOCUS and DATA to a combined adhoc loc. */
|
|
|
|
|
|
|
|
source_location
|
|
|
|
get_combined_adhoc_loc (struct line_maps *set,
|
|
|
|
source_location locus, void *data)
|
|
|
|
{
|
|
|
|
struct location_adhoc_data lb;
|
|
|
|
struct location_adhoc_data **slot;
|
|
|
|
|
|
|
|
linemap_assert (data);
|
|
|
|
|
|
|
|
if (IS_ADHOC_LOC (locus))
|
2014-02-07 17:42:24 +01:00
|
|
|
locus
|
|
|
|
= set->location_adhoc_data_map.data[locus & MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
if (locus == 0 && data == NULL)
|
|
|
|
return 0;
|
|
|
|
lb.locus = locus;
|
|
|
|
lb.data = data;
|
|
|
|
slot = (struct location_adhoc_data **)
|
|
|
|
htab_find_slot (set->location_adhoc_data_map.htab, &lb, INSERT);
|
|
|
|
if (*slot == NULL)
|
|
|
|
{
|
|
|
|
if (set->location_adhoc_data_map.curr_loc >=
|
|
|
|
set->location_adhoc_data_map.allocated)
|
|
|
|
{
|
|
|
|
char *orig_data = (char *) set->location_adhoc_data_map.data;
|
|
|
|
long long offset;
|
2013-01-03 21:06:49 +01:00
|
|
|
/* Cast away extern "C" from the type of xrealloc. */
|
|
|
|
line_map_realloc reallocator = (set->reallocator
|
|
|
|
? set->reallocator
|
|
|
|
: (line_map_realloc) xrealloc);
|
2012-09-25 15:19:33 +02:00
|
|
|
|
|
|
|
if (set->location_adhoc_data_map.allocated == 0)
|
|
|
|
set->location_adhoc_data_map.allocated = 128;
|
|
|
|
else
|
|
|
|
set->location_adhoc_data_map.allocated *= 2;
|
|
|
|
set->location_adhoc_data_map.data = (struct location_adhoc_data *)
|
|
|
|
reallocator (set->location_adhoc_data_map.data,
|
|
|
|
set->location_adhoc_data_map.allocated
|
|
|
|
* sizeof (struct location_adhoc_data));
|
2012-09-19 21:56:42 +02:00
|
|
|
offset = (char *) (set->location_adhoc_data_map.data) - orig_data;
|
2012-09-25 15:19:33 +02:00
|
|
|
if (set->location_adhoc_data_map.allocated > 128)
|
|
|
|
htab_traverse (set->location_adhoc_data_map.htab,
|
|
|
|
location_adhoc_data_update, &offset);
|
2012-09-19 21:56:42 +02:00
|
|
|
}
|
|
|
|
*slot = set->location_adhoc_data_map.data
|
|
|
|
+ set->location_adhoc_data_map.curr_loc;
|
2014-02-07 17:42:24 +01:00
|
|
|
set->location_adhoc_data_map.data[set->location_adhoc_data_map.curr_loc++]
|
|
|
|
= lb;
|
2012-09-19 21:56:42 +02:00
|
|
|
}
|
|
|
|
return ((*slot) - set->location_adhoc_data_map.data) | 0x80000000;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the data for the adhoc loc. */
|
|
|
|
|
|
|
|
void *
|
|
|
|
get_data_from_adhoc_loc (struct line_maps *set, source_location loc)
|
|
|
|
{
|
|
|
|
linemap_assert (IS_ADHOC_LOC (loc));
|
|
|
|
return set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].data;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the location for the adhoc loc. */
|
|
|
|
|
|
|
|
source_location
|
|
|
|
get_location_from_adhoc_loc (struct line_maps *set, source_location loc)
|
|
|
|
{
|
|
|
|
linemap_assert (IS_ADHOC_LOC (loc));
|
|
|
|
return set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Finalize the location_adhoc_data structure. */
|
|
|
|
void
|
|
|
|
location_adhoc_data_fini (struct line_maps *set)
|
|
|
|
{
|
|
|
|
htab_delete (set->location_adhoc_data_map.htab);
|
|
|
|
}
|
|
|
|
|
2001-08-03 01:03:31 +02:00
|
|
|
/* Initialize a line map set. */
|
|
|
|
|
|
|
|
void
|
2014-07-16 12:33:27 +02:00
|
|
|
linemap_init (struct line_maps *set,
|
|
|
|
source_location builtin_location)
|
2001-08-03 01:03:31 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
memset (set, 0, sizeof (struct line_maps));
|
2009-10-14 12:04:22 +02:00
|
|
|
set->highest_location = RESERVED_LOCATION_COUNT - 1;
|
|
|
|
set->highest_line = RESERVED_LOCATION_COUNT - 1;
|
2012-09-25 15:19:33 +02:00
|
|
|
set->location_adhoc_data_map.htab =
|
|
|
|
htab_create (100, location_adhoc_data_hash, location_adhoc_data_eq, NULL);
|
2014-07-16 12:33:27 +02:00
|
|
|
set->builtin_location = builtin_location;
|
2001-08-03 01:03:31 +02:00
|
|
|
}
|
|
|
|
|
2004-02-16 15:20:10 +01:00
|
|
|
/* Check for and warn about line_maps entered but not exited. */
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
|
|
|
|
void
|
|
|
|
linemap_check_files_exited (struct line_maps *set)
|
|
|
|
{
|
|
|
|
struct line_map *map;
|
|
|
|
/* Depending upon whether we are handling preprocessed input or
|
|
|
|
not, this can be a user error or an ICE. */
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
for (map = LINEMAPS_LAST_ORDINARY_MAP (set);
|
|
|
|
! MAIN_FILE_P (map);
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
map = INCLUDED_FROM (set, map))
|
|
|
|
fprintf (stderr, "line-map.c: file \"%s\" entered but not left\n",
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
ORDINARY_MAP_FILE_NAME (map));
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
}
|
2001-08-03 01:03:31 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* Create a new line map in the line map set SET, and return it.
|
|
|
|
REASON is the reason of creating the map. It determines the type
|
|
|
|
of map created (ordinary or macro map). Note that ordinary maps and
|
|
|
|
macro maps are allocated in different memory location. */
|
|
|
|
|
|
|
|
static struct line_map *
|
|
|
|
new_linemap (struct line_maps *set,
|
|
|
|
enum lc_reason reason)
|
2001-08-03 01:03:31 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* Depending on this variable, a macro map would be allocated in a
|
|
|
|
different memory location than an ordinary map. */
|
|
|
|
bool macro_map_p = (reason == LC_ENTER_MACRO);
|
|
|
|
struct line_map *result;
|
|
|
|
|
|
|
|
if (LINEMAPS_USED (set, macro_map_p) == LINEMAPS_ALLOCATED (set, macro_map_p))
|
2001-08-06 23:07:41 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* We ran out of allocated line maps. Let's allocate more. */
|
2011-10-17 12:00:07 +02:00
|
|
|
unsigned alloc_size;
|
2001-08-11 09:33:39 +02:00
|
|
|
|
2013-01-03 21:06:49 +01:00
|
|
|
/* Cast away extern "C" from the type of xrealloc. */
|
|
|
|
line_map_realloc reallocator = (set->reallocator
|
|
|
|
? set->reallocator
|
|
|
|
: (line_map_realloc) xrealloc);
|
2011-10-17 12:00:07 +02:00
|
|
|
line_map_round_alloc_size_func round_alloc_size =
|
|
|
|
set->round_alloc_size;
|
|
|
|
|
|
|
|
/* We are going to execute some dance to try to reduce the
|
|
|
|
overhead of the memory allocator, in case we are using the
|
|
|
|
ggc-page.c one.
|
|
|
|
|
|
|
|
The actual size of memory we are going to get back from the
|
|
|
|
allocator is the smallest power of 2 that is greater than the
|
|
|
|
size we requested. So let's consider that size then. */
|
|
|
|
|
|
|
|
alloc_size =
|
|
|
|
(2 * LINEMAPS_ALLOCATED (set, macro_map_p) + 256)
|
|
|
|
* sizeof (struct line_map);
|
|
|
|
|
|
|
|
/* Get the actual size of memory that is going to be allocated
|
|
|
|
by the allocator. */
|
|
|
|
alloc_size = round_alloc_size (alloc_size);
|
|
|
|
|
|
|
|
/* Now alloc_size contains the exact memory size we would get if
|
|
|
|
we have asked for the initial alloc_size amount of memory.
|
|
|
|
Let's get back to the number of macro map that amounts
|
|
|
|
to. */
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
LINEMAPS_ALLOCATED (set, macro_map_p) =
|
2011-10-17 12:00:07 +02:00
|
|
|
alloc_size / (sizeof (struct line_map));
|
|
|
|
|
|
|
|
/* And now let's really do the re-allocation. */
|
|
|
|
LINEMAPS_MAPS (set, macro_map_p) =
|
|
|
|
(struct line_map *) (*reallocator)
|
|
|
|
(LINEMAPS_MAPS (set, macro_map_p),
|
|
|
|
(LINEMAPS_ALLOCATED (set, macro_map_p)
|
|
|
|
* sizeof (struct line_map)));
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
result =
|
|
|
|
&LINEMAPS_MAPS (set, macro_map_p)[LINEMAPS_USED (set, macro_map_p)];
|
|
|
|
memset (result, 0,
|
|
|
|
((LINEMAPS_ALLOCATED (set, macro_map_p)
|
|
|
|
- LINEMAPS_USED (set, macro_map_p))
|
|
|
|
* sizeof (struct line_map)));
|
2001-08-06 23:07:41 +02:00
|
|
|
}
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
else
|
|
|
|
result =
|
|
|
|
&LINEMAPS_MAPS (set, macro_map_p)[LINEMAPS_USED (set, macro_map_p)];
|
|
|
|
|
|
|
|
LINEMAPS_USED (set, macro_map_p)++;
|
|
|
|
|
|
|
|
result->reason = reason;
|
|
|
|
return result;
|
2001-08-03 01:03:31 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Add a mapping of logical source line to physical source file and
|
2003-07-30 08:43:33 +02:00
|
|
|
line number.
|
|
|
|
|
|
|
|
The text pointed to by TO_FILE must have a lifetime
|
|
|
|
at least as long as the final call to lookup_line (). An empty
|
|
|
|
TO_FILE means standard input. If reason is LC_LEAVE, and
|
|
|
|
TO_FILE is NULL, then TO_FILE, TO_LINE and SYSP are given their
|
|
|
|
natural values considering the file we are returning to.
|
2001-08-03 01:03:31 +02:00
|
|
|
|
|
|
|
FROM_LINE should be monotonic increasing across calls to this
|
2003-07-30 08:43:33 +02:00
|
|
|
function. A call to this function can relocate the previous set of
|
|
|
|
maps, so any stored line_map pointers should not be used. */
|
2001-08-03 01:03:31 +02:00
|
|
|
|
2001-08-11 09:33:39 +02:00
|
|
|
const struct line_map *
|
2003-07-22 18:24:53 +02:00
|
|
|
linemap_add (struct line_maps *set, enum lc_reason reason,
|
2008-07-21 11:33:38 +02:00
|
|
|
unsigned int sysp, const char *to_file, linenum_type to_line)
|
2001-08-03 01:03:31 +02:00
|
|
|
{
|
|
|
|
struct line_map *map;
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
source_location start_location = set->highest_location + 1;
|
2001-08-03 01:03:31 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (!(LINEMAPS_ORDINARY_USED (set)
|
|
|
|
&& (start_location
|
|
|
|
< MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP (set)))));
|
|
|
|
|
|
|
|
/* When we enter the file for the first time reason cannot be
|
|
|
|
LC_RENAME. */
|
|
|
|
linemap_assert (!(set->depth == 0 && reason == LC_RENAME));
|
2001-08-03 01:03:31 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* If we are leaving the main file, return a NULL map. */
|
|
|
|
if (reason == LC_LEAVE
|
|
|
|
&& MAIN_FILE_P (LINEMAPS_LAST_ORDINARY_MAP (set))
|
|
|
|
&& to_file == NULL)
|
2001-08-03 01:03:31 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
set->depth--;
|
|
|
|
return NULL;
|
2001-08-03 01:03:31 +02:00
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
map = new_linemap (set, reason);
|
2001-08-03 01:03:31 +02:00
|
|
|
|
2009-04-18 19:36:28 +02:00
|
|
|
if (to_file && *to_file == '\0' && reason != LC_RENAME_VERBATIM)
|
2003-07-30 08:43:33 +02:00
|
|
|
to_file = "<stdin>";
|
|
|
|
|
2009-04-18 19:36:28 +02:00
|
|
|
if (reason == LC_RENAME_VERBATIM)
|
|
|
|
reason = LC_RENAME;
|
|
|
|
|
2011-08-28 22:14:46 +02:00
|
|
|
if (reason == LC_LEAVE)
|
2001-08-06 23:07:41 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* When we are just leaving an "included" file, and jump to the next
|
|
|
|
location inside the "includer" right after the #include
|
|
|
|
"included", this variable points the map in use right before the
|
|
|
|
#include "included", inside the same "includer" file. */
|
2001-08-11 09:33:39 +02:00
|
|
|
struct line_map *from;
|
|
|
|
bool error;
|
|
|
|
|
|
|
|
if (MAIN_FILE_P (map - 1))
|
2001-08-06 23:07:41 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* So this _should_ means we are leaving the main file --
|
|
|
|
effectively ending the compilation unit. But to_file not
|
|
|
|
being NULL means the caller thinks we are leaving to
|
|
|
|
another file. This is an erroneous behaviour but we'll
|
|
|
|
try to recover from it. Let's pretend we are not leaving
|
|
|
|
the main file. */
|
2003-07-23 01:11:34 +02:00
|
|
|
error = true;
|
|
|
|
reason = LC_RENAME;
|
|
|
|
from = map - 1;
|
2001-08-11 09:33:39 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* (MAP - 1) points to the map we are leaving. The
|
|
|
|
map from which (MAP - 1) got included should be the map
|
|
|
|
that comes right before MAP in the same file. */
|
2001-08-11 09:33:39 +02:00
|
|
|
from = INCLUDED_FROM (set, map - 1);
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
error = to_file && filename_cmp (ORDINARY_MAP_FILE_NAME (from),
|
|
|
|
to_file);
|
2001-08-11 09:33:39 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Depending upon whether we are handling preprocessed input or
|
|
|
|
not, this can be a user error or an ICE. */
|
|
|
|
if (error)
|
|
|
|
fprintf (stderr, "line-map.c: file \"%s\" left but not entered\n",
|
|
|
|
to_file);
|
|
|
|
|
|
|
|
/* A TO_FILE of NULL is special - we use the natural values. */
|
|
|
|
if (error || to_file == NULL)
|
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
to_file = ORDINARY_MAP_FILE_NAME (from);
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
to_line = SOURCE_LINE (from, from[1].start_location);
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from);
|
2001-08-06 23:07:41 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (reason != LC_ENTER_MACRO);
|
|
|
|
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map) = sysp;
|
|
|
|
MAP_START_LOCATION (map) = start_location;
|
|
|
|
ORDINARY_MAP_FILE_NAME (map) = to_file;
|
|
|
|
ORDINARY_MAP_STARTING_LINE_NUMBER (map) = to_line;
|
|
|
|
LINEMAPS_ORDINARY_CACHE (set) = LINEMAPS_ORDINARY_USED (set) - 1;
|
|
|
|
ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) = 0;
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
set->highest_location = start_location;
|
2004-04-23 04:22:27 +02:00
|
|
|
set->highest_line = start_location;
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
set->max_column_hint = 0;
|
2001-08-11 09:33:39 +02:00
|
|
|
|
2001-08-06 23:07:41 +02:00
|
|
|
if (reason == LC_ENTER)
|
2001-08-22 01:05:12 +02:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
ORDINARY_MAP_INCLUDER_FILE_INDEX (map) =
|
|
|
|
set->depth == 0 ? -1 : (int) (LINEMAPS_ORDINARY_USED (set) - 2);
|
2001-08-22 01:05:12 +02:00
|
|
|
set->depth++;
|
|
|
|
if (set->trace_includes)
|
|
|
|
trace_include (set, map);
|
|
|
|
}
|
2001-08-03 01:03:31 +02:00
|
|
|
else if (reason == LC_RENAME)
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
ORDINARY_MAP_INCLUDER_FILE_INDEX (map) =
|
|
|
|
ORDINARY_MAP_INCLUDER_FILE_INDEX (&map[-1]);
|
2001-08-03 01:03:31 +02:00
|
|
|
else if (reason == LC_LEAVE)
|
2001-08-22 01:05:12 +02:00
|
|
|
{
|
|
|
|
set->depth--;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
ORDINARY_MAP_INCLUDER_FILE_INDEX (map) =
|
|
|
|
ORDINARY_MAP_INCLUDER_FILE_INDEX (INCLUDED_FROM (set, map - 1));
|
2001-08-22 01:05:12 +02:00
|
|
|
}
|
2001-08-21 23:17:48 +02:00
|
|
|
|
2001-08-03 01:03:31 +02:00
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
2012-05-29 16:53:50 +02:00
|
|
|
/* Returns TRUE if the line table set tracks token locations across
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
macro expansion, FALSE otherwise. */
|
|
|
|
|
|
|
|
bool
|
|
|
|
linemap_tracks_macro_expansion_locs_p (struct line_maps *set)
|
|
|
|
{
|
|
|
|
return LINEMAPS_MACRO_MAPS (set) != NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create a macro map. A macro map encodes source locations of tokens
|
|
|
|
that are part of a macro replacement-list, at a macro expansion
|
|
|
|
point. See the extensive comments of struct line_map and struct
|
|
|
|
line_map_macro, in line-map.h.
|
|
|
|
|
|
|
|
This map shall be created when the macro is expanded. The map
|
|
|
|
encodes the source location of the expansion point of the macro as
|
|
|
|
well as the "original" source location of each token that is part
|
|
|
|
of the macro replacement-list. If a macro is defined but never
|
|
|
|
expanded, it has no macro map. SET is the set of maps the macro
|
|
|
|
map should be part of. MACRO_NODE is the macro which the new macro
|
|
|
|
map should encode source locations for. EXPANSION is the location
|
|
|
|
of the expansion point of MACRO. For function-like macros
|
|
|
|
invocations, it's best to make it point to the closing parenthesis
|
|
|
|
of the macro, rather than the the location of the first character
|
|
|
|
of the macro. NUM_TOKENS is the number of tokens that are part of
|
|
|
|
the replacement-list of MACRO.
|
|
|
|
|
|
|
|
Note that when we run out of the integer space available for source
|
|
|
|
locations, this function returns NULL. In that case, callers of
|
|
|
|
this function cannot encode {line,column} pairs into locations of
|
|
|
|
macro tokens anymore. */
|
|
|
|
|
|
|
|
const struct line_map *
|
|
|
|
linemap_enter_macro (struct line_maps *set, struct cpp_hashnode *macro_node,
|
|
|
|
source_location expansion, unsigned int num_tokens)
|
|
|
|
{
|
|
|
|
struct line_map *map;
|
|
|
|
source_location start_location;
|
2013-01-03 21:06:49 +01:00
|
|
|
/* Cast away extern "C" from the type of xrealloc. */
|
|
|
|
line_map_realloc reallocator = (set->reallocator
|
|
|
|
? set->reallocator
|
|
|
|
: (line_map_realloc) xrealloc);
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
start_location = LINEMAPS_MACRO_LOWEST_LOCATION (set) - num_tokens;
|
|
|
|
|
|
|
|
if (start_location <= set->highest_line
|
|
|
|
|| start_location > LINEMAPS_MACRO_LOWEST_LOCATION (set))
|
|
|
|
/* We ran out of macro map space. */
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
map = new_linemap (set, LC_ENTER_MACRO);
|
|
|
|
|
|
|
|
MAP_START_LOCATION (map) = start_location;
|
|
|
|
MACRO_MAP_MACRO (map) = macro_node;
|
|
|
|
MACRO_MAP_NUM_MACRO_TOKENS (map) = num_tokens;
|
|
|
|
MACRO_MAP_LOCATIONS (map)
|
|
|
|
= (source_location*) reallocator (NULL,
|
|
|
|
2 * num_tokens
|
|
|
|
* sizeof (source_location));
|
|
|
|
MACRO_MAP_EXPANSION_POINT_LOCATION (map) = expansion;
|
|
|
|
memset (MACRO_MAP_LOCATIONS (map), 0,
|
|
|
|
num_tokens * sizeof (source_location));
|
|
|
|
|
|
|
|
LINEMAPS_MACRO_CACHE (set) = LINEMAPS_MACRO_USED (set) - 1;
|
|
|
|
|
|
|
|
return map;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Create and return a virtual location for a token that is part of a
|
|
|
|
macro expansion-list at a macro expansion point. See the comment
|
|
|
|
inside struct line_map_macro to see what an expansion-list exactly
|
|
|
|
is.
|
|
|
|
|
|
|
|
A call to this function must come after a call to
|
|
|
|
linemap_enter_macro.
|
|
|
|
|
|
|
|
MAP is the map into which the source location is created. TOKEN_NO
|
|
|
|
is the index of the token in the macro replacement-list, starting
|
|
|
|
at number 0.
|
|
|
|
|
|
|
|
ORIG_LOC is the location of the token outside of this macro
|
|
|
|
expansion. If the token comes originally from the macro
|
|
|
|
definition, it is the locus in the macro definition; otherwise it
|
|
|
|
is a location in the context of the caller of this macro expansion
|
|
|
|
(which is a virtual location or a source location if the caller is
|
|
|
|
itself a macro expansion or not).
|
|
|
|
|
2014-10-14 16:45:36 +02:00
|
|
|
ORIG_PARM_REPLACEMENT_LOC is the location in the macro definition,
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
either of the token itself or of a macro parameter that it
|
|
|
|
replaces. */
|
|
|
|
|
|
|
|
source_location
|
|
|
|
linemap_add_macro_token (const struct line_map *map,
|
|
|
|
unsigned int token_no,
|
|
|
|
source_location orig_loc,
|
|
|
|
source_location orig_parm_replacement_loc)
|
|
|
|
{
|
|
|
|
source_location result;
|
|
|
|
|
|
|
|
linemap_assert (linemap_macro_expansion_map_p (map));
|
|
|
|
linemap_assert (token_no < MACRO_MAP_NUM_MACRO_TOKENS (map));
|
|
|
|
|
|
|
|
MACRO_MAP_LOCATIONS (map)[2 * token_no] = orig_loc;
|
|
|
|
MACRO_MAP_LOCATIONS (map)[2 * token_no + 1] = orig_parm_replacement_loc;
|
|
|
|
|
|
|
|
result = MAP_START_LOCATION (map) + token_no;
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a source_location for the start (i.e. column==0) of
|
|
|
|
(physical) line TO_LINE in the current source file (as in the
|
|
|
|
most recent linemap_add). MAX_COLUMN_HINT is the highest column
|
|
|
|
number we expect to use in this line (but it does not change
|
|
|
|
the highest_location). */
|
|
|
|
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
source_location
|
2008-07-21 11:33:38 +02:00
|
|
|
linemap_line_start (struct line_maps *set, linenum_type to_line,
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
unsigned int max_column_hint)
|
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
struct line_map *map = LINEMAPS_LAST_ORDINARY_MAP (set);
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
source_location highest = set->highest_location;
|
|
|
|
source_location r;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linenum_type last_line =
|
|
|
|
SOURCE_LINE (map, set->highest_line);
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
int line_delta = to_line - last_line;
|
|
|
|
bool add_map = false;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
if (line_delta < 0
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|| (line_delta > 10
|
|
|
|
&& line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > 1000)
|
|
|
|
|| (max_column_hint >= (1U << ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)))
|
|
|
|
|| (max_column_hint <= 80
|
2014-11-25 12:16:27 +01:00
|
|
|
&& ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) >= 10)
|
|
|
|
|| (highest > 0x60000000
|
|
|
|
&& (set->max_column_hint || highest > 0x70000000)))
|
|
|
|
add_map = true;
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
else
|
|
|
|
max_column_hint = set->max_column_hint;
|
|
|
|
if (add_map)
|
|
|
|
{
|
|
|
|
int column_bits;
|
2012-09-19 21:56:42 +02:00
|
|
|
if (max_column_hint > 100000 || highest > 0x60000000)
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
{
|
2005-04-21 19:08:27 +02:00
|
|
|
/* If the column number is ridiculous or we've allocated a huge
|
|
|
|
number of source_locations, give up on column numbers. */
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
max_column_hint = 0;
|
2014-11-25 12:16:27 +01:00
|
|
|
if (highest > 0x70000000)
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
return 0;
|
|
|
|
column_bits = 0;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
column_bits = 7;
|
|
|
|
while (max_column_hint >= (1U << column_bits))
|
|
|
|
column_bits++;
|
|
|
|
max_column_hint = 1U << column_bits;
|
|
|
|
}
|
2005-04-21 19:08:27 +02:00
|
|
|
/* Allocate the new line_map. However, if the current map only has a
|
|
|
|
single line we can sometimes just increase its column_bits instead. */
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
if (line_delta < 0
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
|| SOURCE_COLUMN (map, highest) >= (1U << column_bits))
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
map = (struct line_map *) linemap_add (set, LC_RENAME,
|
|
|
|
ORDINARY_MAP_IN_SYSTEM_HEADER_P
|
|
|
|
(map),
|
|
|
|
ORDINARY_MAP_FILE_NAME (map),
|
|
|
|
to_line);
|
|
|
|
ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) = column_bits;
|
|
|
|
r = (MAP_START_LOCATION (map)
|
|
|
|
+ ((to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
|
|
|
|
<< column_bits));
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
}
|
|
|
|
else
|
|
|
|
r = highest - SOURCE_COLUMN (map, highest)
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
+ (line_delta << ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map));
|
|
|
|
|
|
|
|
/* Locations of ordinary tokens are always lower than locations of
|
|
|
|
macro tokens. */
|
|
|
|
if (r >= LINEMAPS_MACRO_LOWEST_LOCATION (set))
|
|
|
|
return 0;
|
|
|
|
|
2004-04-23 04:22:27 +02:00
|
|
|
set->highest_line = r;
|
Represent column numbers using line-map's source_location.
The "next available source_location" is now managed internally by
line-maps.c rather than by clients.
* line-map.h (struct line_map): New field column_bits.
<from_line>: Rename field to start_location.
(struct line_maps): New fields highest_location and max_column_hint.
(linemap_check_files_exited): New declaration.
(linemap_line_start): New declaration.
(linemap_add): Remove from_line parameter; use highest_location field.
(SOURCE_LINE, LAST_SOURCE_LINE): Modify to use column_bits.
(SOURCE_COLUMN, LAST_SOURCE_LINE_LOCATION): New macros.
(CURRENT_LINE_MAP): Remove macro.
(linemap_position_for_column): New inline function.
* line-map.c (linemap_init): Clear new fields.
(linemap_check_files_exited): New function, extracted from ...
(linemap_free): Use linemap_check_files_exited.
(linemap_add): Remove from_line parameter. Various updates.
(linemap_line_start): New function.
(linemap_lookeup): Update for new field names.
* cpphash.h (struct cpp_reader) <map>: Field removed. Because
linemap_position_for_column may unpredictably change the current map,
it is cleaner and simpler for us to not cache it in cpp_reader.
(struct cpp_buffer): New sysp field.
Changed warned_cplusplus_comments and from_stage3 to bitfields.
* cppinit.c (cpp_read_min_file): pfile->map no longer exists.
* cpplib.c (do_line, do_linemarker, _cpp_do_file_change): Get
current map using linemap_lookup.
(do_linemarker): Also set buffer's sysp field.
(destringize_and_run): No longer need to decrement current line.
* cppfiles.c (_cpp_stack_file): Set sysp from and in buffer.
(search_path_head, open_file_failed): Use buffer's sysp.
(cpp_make_system_header): Get current map using linemap_lookup.
Also set buffer's sysp flag.
* cppmacro.c (_cpp_builtin_macro_text): Likewise use linemap_lookup.
* cpphash.h (CPP_INCREMENT_LINE): New macro.
(struct cpp_buffer): Moved fields saved_cur, saved_rlimit to ...
(struct cpp_reader): ... and adding saved_line_base field.
* cpptrad.c (_cpp_overlay_buffer, _cpp_remove_overlay):
Update accordingly. Don't adjust line.
(_cpp_scan_out_logical_line): Use CPP_INCREMENT_LINE.
* cpphash.c (CPP_IN_SYSTEM_HEADER): Replaced macro by ...
(cpp_in_system_header): ... new inline function, using buffer's sysp.
* cpperror.c (_cpp_begin_message): Update to use cpp_in_system_header.
* cpplex.c (_cpp_lex_direct): Likewise.
* cppmacro.c (_cpp_builtin_macro_text): Likewise.
* cppmacro.c (_cpp_create_definition): Use buffer's sysp field.
* cpplib.h (struct cpp_token): Rename line field to src_loc.
Remove col field as it is now subsumed by src_loc.
* cpperror.c: Update various field, parameter, and macro names.
(print_location): If col==0, try SOURCE_COLUMN of line.
(cpp_error): Use cur_token's src_loc field, rather than line+col.
* cpplib.c (do_diagnostic): Token's src_loc fields replaces line+col.
* cpplex.c (_cpp_process_line_notes, _cpp_lex_direct,
_cpp_skip_block_comment): Use CPP_INCREMENT_LINE.
(_cpp_temp_token): Replace cpp_token's line+col fields by src_loc.
(_cpp_get_fresh_line): Don't need to adjust line for missing newline.
(_cpp_lex_direct): Use linemap_position_for_column.
* c-ppoutput.c (maybe_print_line, print_line): Don't take map
parameter. Instead get it from the line_table global. Adjust callers.
(print): Remove map field. Replace line field to src_line.
(init_pp_output, account_for_newlines, maybe_print_line): Adjust.
(cb_line_change): Use SOURCE_COLUMN. Minor optimizations.
(pp_file_change): Use MAIN_FILE_P since we cannot checked print.map.
Use LAST_SOURCE_LINE_LOCATION to "catch up" after #include.
* cpptrad.c (copy_comment): Rename variable.
* c-lex.c (map): Remove static variable, for same reason we removed
cpp_reader's map field.
(cb_line_change, cb_def_pragma, cb_define, cb_undef): Hence we need
to call linemap_lookup.
(cb_line_change): Token's line field replaced by src_loc.
(fe_file_change): Use MAINFILE_P and LAST_SOURCE_LINE macros.
Don't save new_map.
* cpphash.h, cpperror.c, cpplib.h: Some renames of fileline to
source_location.
From-SVN: r77663
2004-02-11 16:29:30 +01:00
|
|
|
if (r > set->highest_location)
|
|
|
|
set->highest_location = r;
|
|
|
|
set->max_column_hint = max_column_hint;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* Encode and return a source_location from a column number. The
|
|
|
|
source line considered is the last source line used to call
|
|
|
|
linemap_line_start, i.e, the last source line which a location was
|
|
|
|
encoded from. */
|
|
|
|
|
2004-04-23 04:22:27 +02:00
|
|
|
source_location
|
|
|
|
linemap_position_for_column (struct line_maps *set, unsigned int to_column)
|
|
|
|
{
|
|
|
|
source_location r = set->highest_line;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
linemap_assert
|
|
|
|
(!linemap_macro_expansion_map_p (LINEMAPS_LAST_ORDINARY_MAP (set)));
|
|
|
|
|
2004-04-23 04:22:27 +02:00
|
|
|
if (to_column >= set->max_column_hint)
|
|
|
|
{
|
|
|
|
if (r >= 0xC000000 || to_column > 100000)
|
|
|
|
{
|
|
|
|
/* Running low on source_locations - disable column numbers. */
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
struct line_map *map = LINEMAPS_LAST_ORDINARY_MAP (set);
|
2004-04-23 04:22:27 +02:00
|
|
|
r = linemap_line_start (set, SOURCE_LINE (map, r), to_column + 50);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
r = r + to_column;
|
|
|
|
if (r >= set->highest_location)
|
|
|
|
set->highest_location = r;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* Encode and return a source location from a given line and
|
|
|
|
column. */
|
2001-08-03 01:03:31 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
source_location
|
2014-10-14 16:45:36 +02:00
|
|
|
linemap_position_for_line_and_column (const struct line_map *map,
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linenum_type line,
|
|
|
|
unsigned column)
|
|
|
|
{
|
|
|
|
linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (map) <= line);
|
|
|
|
|
|
|
|
return (MAP_START_LOCATION (map)
|
|
|
|
+ ((line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
|
|
|
|
<< ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map))
|
|
|
|
+ (column & ((1 << ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)) - 1)));
|
|
|
|
}
|
|
|
|
|
2014-11-11 23:50:48 +01:00
|
|
|
/* Encode and return a source_location starting from location LOC and
|
|
|
|
shifting it by OFFSET columns. This function does not support
|
|
|
|
virtual locations. */
|
|
|
|
|
|
|
|
source_location
|
|
|
|
linemap_position_for_loc_and_offset (struct line_maps *set,
|
|
|
|
source_location loc,
|
|
|
|
unsigned int offset)
|
|
|
|
{
|
|
|
|
const struct line_map * map = NULL;
|
|
|
|
|
|
|
|
/* This function does not support virtual locations yet. */
|
|
|
|
linemap_assert (!linemap_location_from_macro_expansion_p (set, loc));
|
|
|
|
|
|
|
|
if (offset == 0
|
|
|
|
/* Adding an offset to a reserved location (like
|
|
|
|
UNKNOWN_LOCATION for the C/C++ FEs) does not really make
|
|
|
|
sense. So let's leave the location intact in that case. */
|
|
|
|
|| loc < RESERVED_LOCATION_COUNT)
|
|
|
|
return loc;
|
|
|
|
|
|
|
|
/* We find the real location and shift it. */
|
|
|
|
loc = linemap_resolve_location (set, loc, LRK_SPELLING_LOCATION, &map);
|
|
|
|
/* The new location (loc + offset) should be higher than the first
|
|
|
|
location encoded by MAP. */
|
|
|
|
linemap_assert (MAP_START_LOCATION (map) < loc + offset);
|
|
|
|
|
|
|
|
/* If MAP is not the last line map of its set, then the new location
|
|
|
|
(loc + offset) should be less than the first location encoded by
|
|
|
|
the next line map of the set. */
|
|
|
|
if (map != LINEMAPS_LAST_ORDINARY_MAP (set))
|
|
|
|
linemap_assert (loc + offset < MAP_START_LOCATION (&map[1]));
|
|
|
|
|
|
|
|
offset += SOURCE_COLUMN (map, loc);
|
|
|
|
linemap_assert (offset < (1u << map->d.ordinary.column_bits));
|
|
|
|
|
|
|
|
source_location r =
|
|
|
|
linemap_position_for_line_and_column (map,
|
|
|
|
SOURCE_LINE (map, loc),
|
|
|
|
offset);
|
|
|
|
linemap_assert (map == linemap_lookup (set, r));
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* Given a virtual source location yielded by a map (either an
|
|
|
|
ordinary or a macro map), returns that map. */
|
|
|
|
|
|
|
|
const struct line_map*
|
2003-12-05 21:52:39 +01:00
|
|
|
linemap_lookup (struct line_maps *set, source_location line)
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
{
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (line))
|
|
|
|
line = set->location_adhoc_data_map.data[line & MAX_SOURCE_LOCATION].locus;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (linemap_location_from_macro_expansion_p (set, line))
|
|
|
|
return linemap_macro_map_lookup (set, line);
|
|
|
|
return linemap_ordinary_map_lookup (set, line);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Given a source location yielded by an ordinary map, returns that
|
|
|
|
map. Since the set is built chronologically, the logical lines are
|
|
|
|
monotonic increasing, and so the list is sorted and we can use a
|
|
|
|
binary search. */
|
|
|
|
|
|
|
|
static const struct line_map *
|
|
|
|
linemap_ordinary_map_lookup (struct line_maps *set, source_location line)
|
2001-08-03 01:03:31 +02:00
|
|
|
{
|
2004-01-20 06:17:48 +01:00
|
|
|
unsigned int md, mn, mx;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
const struct line_map *cached, *result;
|
2004-01-20 06:17:48 +01:00
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (line))
|
|
|
|
line = set->location_adhoc_data_map.data[line & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (set == NULL || line < RESERVED_LOCATION_COUNT)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mn = LINEMAPS_ORDINARY_CACHE (set);
|
|
|
|
mx = LINEMAPS_ORDINARY_USED (set);
|
2004-01-20 06:17:48 +01:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
cached = LINEMAPS_ORDINARY_MAP_AT (set, mn);
|
2004-02-16 15:20:10 +01:00
|
|
|
/* We should get a segfault if no line_maps have been added yet. */
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (line >= MAP_START_LOCATION (cached))
|
2004-01-20 06:17:48 +01:00
|
|
|
{
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (mn + 1 == mx || line < MAP_START_LOCATION (&cached[1]))
|
2004-01-20 06:17:48 +01:00
|
|
|
return cached;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
mx = mn;
|
|
|
|
mn = 0;
|
|
|
|
}
|
2001-08-03 01:03:31 +02:00
|
|
|
|
|
|
|
while (mx - mn > 1)
|
|
|
|
{
|
|
|
|
md = (mn + mx) / 2;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (MAP_START_LOCATION (LINEMAPS_ORDINARY_MAP_AT (set, md)) > line)
|
2001-08-03 01:03:31 +02:00
|
|
|
mx = md;
|
|
|
|
else
|
|
|
|
mn = md;
|
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
LINEMAPS_ORDINARY_CACHE (set) = mn;
|
|
|
|
result = LINEMAPS_ORDINARY_MAP_AT (set, mn);
|
|
|
|
linemap_assert (line >= MAP_START_LOCATION (result));
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Given a source location yielded by a macro map, returns that map.
|
|
|
|
Since the set is built chronologically, the logical lines are
|
|
|
|
monotonic decreasing, and so the list is sorted and we can use a
|
|
|
|
binary search. */
|
|
|
|
|
|
|
|
static const struct line_map*
|
|
|
|
linemap_macro_map_lookup (struct line_maps *set, source_location line)
|
|
|
|
{
|
|
|
|
unsigned int md, mn, mx;
|
|
|
|
const struct line_map *cached, *result;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (line))
|
|
|
|
line = set->location_adhoc_data_map.data[line & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
|
|
|
|
|
|
|
|
if (set == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
mn = LINEMAPS_MACRO_CACHE (set);
|
|
|
|
mx = LINEMAPS_MACRO_USED (set);
|
|
|
|
cached = LINEMAPS_MACRO_MAP_AT (set, mn);
|
|
|
|
|
|
|
|
if (line >= MAP_START_LOCATION (cached))
|
|
|
|
{
|
|
|
|
if (mn == 0 || line < MAP_START_LOCATION (&cached[-1]))
|
|
|
|
return cached;
|
|
|
|
mx = mn - 1;
|
|
|
|
mn = 0;
|
|
|
|
}
|
|
|
|
|
2011-10-25 10:59:07 +02:00
|
|
|
while (mn < mx)
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
{
|
|
|
|
md = (mx + mn) / 2;
|
|
|
|
if (MAP_START_LOCATION (LINEMAPS_MACRO_MAP_AT (set, md)) > line)
|
2011-10-25 10:59:07 +02:00
|
|
|
mn = md + 1;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
else
|
|
|
|
mx = md;
|
2011-10-25 10:59:07 +02:00
|
|
|
}
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
LINEMAPS_MACRO_CACHE (set) = mx;
|
|
|
|
result = LINEMAPS_MACRO_MAP_AT (set, LINEMAPS_MACRO_CACHE (set));
|
|
|
|
linemap_assert (MAP_START_LOCATION (result) <= line);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return TRUE if MAP encodes locations coming from a macro
|
|
|
|
replacement-list at macro expansion point. */
|
|
|
|
|
|
|
|
bool
|
|
|
|
linemap_macro_expansion_map_p (const struct line_map *map)
|
|
|
|
{
|
|
|
|
if (!map)
|
|
|
|
return false;
|
|
|
|
return (map->reason == LC_ENTER_MACRO);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If LOCATION is the locus of a token in a replacement-list of a
|
|
|
|
macro expansion return the location of the macro expansion point.
|
|
|
|
|
|
|
|
Read the comments of struct line_map and struct line_map_macro in
|
|
|
|
line-map.h to understand what a macro expansion point is. */
|
|
|
|
|
2011-10-17 16:01:37 +02:00
|
|
|
static source_location
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_macro_map_loc_to_exp_point (const struct line_map *map,
|
2011-10-17 16:01:37 +02:00
|
|
|
source_location location ATTRIBUTE_UNUSED)
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
{
|
|
|
|
linemap_assert (linemap_macro_expansion_map_p (map)
|
|
|
|
&& location >= MAP_START_LOCATION (map));
|
|
|
|
|
|
|
|
/* Make sure LOCATION is correct. */
|
2011-10-17 16:01:37 +02:00
|
|
|
linemap_assert ((location - MAP_START_LOCATION (map))
|
|
|
|
< MACRO_MAP_NUM_MACRO_TOKENS (map));
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
return MACRO_MAP_EXPANSION_POINT_LOCATION (map);
|
|
|
|
}
|
|
|
|
|
2014-10-14 16:45:36 +02:00
|
|
|
/* LOCATION is the source location of a token that belongs to a macro
|
|
|
|
replacement-list as part of the macro expansion denoted by MAP.
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
2014-10-14 16:45:36 +02:00
|
|
|
Return the location of the token at the definition point of the
|
|
|
|
macro. */
|
|
|
|
|
|
|
|
static source_location
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_macro_map_loc_to_def_point (const struct line_map *map,
|
|
|
|
source_location location)
|
|
|
|
{
|
|
|
|
unsigned token_no;
|
|
|
|
|
|
|
|
linemap_assert (linemap_macro_expansion_map_p (map)
|
|
|
|
&& location >= MAP_START_LOCATION (map));
|
|
|
|
linemap_assert (location >= RESERVED_LOCATION_COUNT);
|
|
|
|
|
|
|
|
token_no = location - MAP_START_LOCATION (map);
|
|
|
|
linemap_assert (token_no < MACRO_MAP_NUM_MACRO_TOKENS (map));
|
|
|
|
|
|
|
|
location = MACRO_MAP_LOCATIONS (map)[2 * token_no + 1];
|
|
|
|
|
|
|
|
return location;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If LOCATION is the locus of a token that is an argument of a
|
|
|
|
function-like macro M and appears in the expansion of M, return the
|
|
|
|
locus of that argument in the context of the caller of M.
|
|
|
|
|
|
|
|
In other words, this returns the xI location presented in the
|
|
|
|
comments of line_map_macro above. */
|
|
|
|
source_location
|
|
|
|
linemap_macro_map_loc_unwind_toward_spelling (const struct line_map* map,
|
|
|
|
source_location location)
|
|
|
|
{
|
|
|
|
unsigned token_no;
|
|
|
|
|
|
|
|
linemap_assert (linemap_macro_expansion_map_p (map)
|
|
|
|
&& location >= MAP_START_LOCATION (map));
|
|
|
|
linemap_assert (location >= RESERVED_LOCATION_COUNT);
|
|
|
|
|
|
|
|
token_no = location - MAP_START_LOCATION (map);
|
|
|
|
linemap_assert (token_no < MACRO_MAP_NUM_MACRO_TOKENS (map));
|
|
|
|
|
|
|
|
location = MACRO_MAP_LOCATIONS (map)[2 * token_no];
|
|
|
|
|
|
|
|
return location;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the source line number corresponding to source location
|
|
|
|
LOCATION. SET is the line map set LOCATION comes from. If
|
|
|
|
LOCATION is the source location of token that is part of the
|
|
|
|
replacement-list of a macro expansion return the line number of the
|
|
|
|
macro expansion point. */
|
|
|
|
|
|
|
|
int
|
|
|
|
linemap_get_expansion_line (struct line_maps *set,
|
|
|
|
source_location location)
|
|
|
|
{
|
|
|
|
const struct line_map *map = NULL;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (location < RESERVED_LOCATION_COUNT)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
location =
|
|
|
|
linemap_macro_loc_to_exp_point (set, location, &map);
|
|
|
|
|
|
|
|
return SOURCE_LINE (map, location);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the path of the file corresponding to source code location
|
|
|
|
LOCATION.
|
|
|
|
|
|
|
|
If LOCATION is the source location of token that is part of the
|
|
|
|
replacement-list of a macro expansion return the file path of the
|
|
|
|
macro expansion point.
|
|
|
|
|
|
|
|
SET is the line map set LOCATION comes from. */
|
|
|
|
|
|
|
|
const char*
|
|
|
|
linemap_get_expansion_filename (struct line_maps *set,
|
|
|
|
source_location location)
|
|
|
|
{
|
|
|
|
const struct line_map *map = NULL;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (location < RESERVED_LOCATION_COUNT)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
location =
|
|
|
|
linemap_macro_loc_to_exp_point (set, location, &map);
|
|
|
|
|
|
|
|
return LINEMAP_FILE (map);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the name of the macro associated to MACRO_MAP. */
|
|
|
|
|
|
|
|
const char*
|
|
|
|
linemap_map_get_macro_name (const struct line_map* macro_map)
|
|
|
|
{
|
|
|
|
linemap_assert (macro_map && linemap_macro_expansion_map_p (macro_map));
|
|
|
|
return (const char*) NODE_NAME (MACRO_MAP_MACRO (macro_map));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a positive value if LOCATION is the locus of a token that is
|
|
|
|
located in a system header, O otherwise. It returns 1 if LOCATION
|
|
|
|
is the locus of a token that is located in a system header, and 2
|
|
|
|
if LOCATION is the locus of a token located in a C system header
|
|
|
|
that therefore needs to be extern "C" protected in C++.
|
|
|
|
|
|
|
|
Note that this function returns 1 if LOCATION belongs to a token
|
|
|
|
that is part of a macro replacement-list defined in a system
|
|
|
|
header, but expanded in a non-system file. */
|
|
|
|
|
|
|
|
int
|
|
|
|
linemap_location_in_system_header_p (struct line_maps *set,
|
|
|
|
source_location location)
|
|
|
|
{
|
|
|
|
const struct line_map *map = NULL;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
2011-10-25 10:58:54 +02:00
|
|
|
if (location < RESERVED_LOCATION_COUNT)
|
|
|
|
return false;
|
|
|
|
|
PR preprocessor/53463 - Fix system header detection for built-in macro tokens
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile with -pedantic, like in the test case accompanying
this patch.
In that case, I think we ought to step-up to see where the built-in
macro has been expanded, until we see a location that is not for a
built-in macro. Then we can check if the resulting location is in a
system header or not.
Now that we step up to the location of first non-built-in-macro token,
it appeared that for
testsuite/c-c++-common/dfp/convert-int-saturate.c, G++ then fails to
emit the warning in:
volatile unsigned int usi;
int
main ()
{
usi = DEC32_MAX; /* { dg-warning "overflow in implicit constant conversion" } */
...
}
Because DEC32_MAX is defined in the system header float.h as a
built-in macro:
#define DEC32_MAX __DEC32_MAX__
And during the parsing of the assignment expression that should have
led to the warning above, input_location is set to the location for
the DEC32_MAX, which is actually the location for the built-in
__DECL32_MAX_EXP.
A possible fix is to use the location of the "=" operator as the
default location for assignment expressions. This is what the patch
does.
I had to adjust a couple of tests to arrange for this.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
libcpp/
PR preprocessor/53463
* line-map.c (linemap_location_in_system_header_p): For built-in
macro tokens, check the first expansion point location for that is
not for a token coming from a built-in macro.
gcc/cp/
PR preprocessor/53463
* parser.c (cp_parser_assignment_expression): Use the location
for the LHS as the default location for the expression.
gcc/testsuite/
PR preprocessor/53463
* g++.dg/cpp/limits.C: New test.
* g++.dg/parse/error19.C: Adjust.
* g++.dg/warn/Wconversion-real-integer2.C: Likewise.
* g++.dg/warn/pr35635.C: Likewise.
* g++.old-deja/g++.pt/assign1.C: Likewise.
From-SVN: r188203
2012-06-04 21:19:58 +02:00
|
|
|
/* Let's look at where the token for LOCATION comes from. */
|
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
map = linemap_lookup (set, location);
|
|
|
|
if (map != NULL)
|
|
|
|
{
|
|
|
|
if (!linemap_macro_expansion_map_p (map))
|
|
|
|
/* It's a normal token. */
|
|
|
|
return LINEMAP_SYSP (map);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* It's a token resulting from a macro expansion. */
|
|
|
|
source_location loc =
|
|
|
|
linemap_macro_map_loc_unwind_toward_spelling (map, location);
|
|
|
|
if (loc < RESERVED_LOCATION_COUNT)
|
|
|
|
/* This token might come from a built-in macro. Let's
|
|
|
|
look at where that macro got expanded. */
|
|
|
|
location = linemap_macro_map_loc_to_exp_point (map, location);
|
|
|
|
else
|
|
|
|
location = loc;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false;
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return TRUE if LOCATION is a source code location of a token coming
|
|
|
|
from a macro replacement-list at a macro expansion point, FALSE
|
|
|
|
otherwise. */
|
|
|
|
|
|
|
|
bool
|
2014-10-14 16:45:36 +02:00
|
|
|
linemap_location_from_macro_expansion_p (const struct line_maps *set,
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
source_location location)
|
|
|
|
{
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (location <= MAX_SOURCE_LOCATION
|
|
|
|
&& (set->highest_location
|
|
|
|
< LINEMAPS_MACRO_LOWEST_LOCATION (set)));
|
|
|
|
if (set == NULL)
|
|
|
|
return false;
|
|
|
|
return (location > set->highest_location);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Given two virtual locations *LOC0 and *LOC1, return the first
|
|
|
|
common macro map in their macro expansion histories. Return NULL
|
|
|
|
if no common macro was found. *LOC0 (resp. *LOC1) is set to the
|
|
|
|
virtual location of the token inside the resulting macro. */
|
|
|
|
|
|
|
|
static const struct line_map*
|
|
|
|
first_map_in_common_1 (struct line_maps *set,
|
|
|
|
source_location *loc0,
|
|
|
|
source_location *loc1)
|
|
|
|
{
|
|
|
|
source_location l0 = *loc0, l1 = *loc1;
|
|
|
|
const struct line_map *map0 = linemap_lookup (set, l0),
|
|
|
|
*map1 = linemap_lookup (set, l1);
|
|
|
|
|
|
|
|
while (linemap_macro_expansion_map_p (map0)
|
|
|
|
&& linemap_macro_expansion_map_p (map1)
|
|
|
|
&& (map0 != map1))
|
|
|
|
{
|
|
|
|
if (MAP_START_LOCATION (map0) < MAP_START_LOCATION (map1))
|
|
|
|
{
|
|
|
|
l0 = linemap_macro_map_loc_to_exp_point (map0, l0);
|
|
|
|
map0 = linemap_lookup (set, l0);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
l1 = linemap_macro_map_loc_to_exp_point (map1, l1);
|
|
|
|
map1 = linemap_lookup (set, l1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (map0 == map1)
|
|
|
|
{
|
|
|
|
*loc0 = l0;
|
|
|
|
*loc1 = l1;
|
|
|
|
return map0;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Given two virtual locations LOC0 and LOC1, return the first common
|
|
|
|
macro map in their macro expansion histories. Return NULL if no
|
|
|
|
common macro was found. *RES_LOC0 (resp. *RES_LOC1) is set to the
|
|
|
|
virtual location of the token inside the resulting macro, upon
|
|
|
|
return of a non-NULL result. */
|
|
|
|
|
|
|
|
static const struct line_map*
|
|
|
|
first_map_in_common (struct line_maps *set,
|
|
|
|
source_location loc0,
|
|
|
|
source_location loc1,
|
|
|
|
source_location *res_loc0,
|
|
|
|
source_location *res_loc1)
|
|
|
|
{
|
|
|
|
*res_loc0 = loc0;
|
|
|
|
*res_loc1 = loc1;
|
|
|
|
|
|
|
|
return first_map_in_common_1 (set, res_loc0, res_loc1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return a positive value if PRE denotes the location of a token that
|
|
|
|
comes before the token of POST, 0 if PRE denotes the location of
|
|
|
|
the same token as the token for POST, and a negative value
|
|
|
|
otherwise. */
|
|
|
|
|
|
|
|
int
|
|
|
|
linemap_compare_locations (struct line_maps *set,
|
|
|
|
source_location pre,
|
|
|
|
source_location post)
|
|
|
|
{
|
|
|
|
bool pre_virtual_p, post_virtual_p;
|
|
|
|
source_location l0 = pre, l1 = post;
|
|
|
|
|
2014-02-07 17:42:24 +01:00
|
|
|
if (IS_ADHOC_LOC (l0))
|
|
|
|
l0 = set->location_adhoc_data_map.data[l0 & MAX_SOURCE_LOCATION].locus;
|
|
|
|
if (IS_ADHOC_LOC (l1))
|
|
|
|
l1 = set->location_adhoc_data_map.data[l1 & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
if (l0 == l1)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if ((pre_virtual_p = linemap_location_from_macro_expansion_p (set, l0)))
|
|
|
|
l0 = linemap_resolve_location (set, l0,
|
|
|
|
LRK_MACRO_EXPANSION_POINT,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
if ((post_virtual_p = linemap_location_from_macro_expansion_p (set, l1)))
|
|
|
|
l1 = linemap_resolve_location (set, l1,
|
|
|
|
LRK_MACRO_EXPANSION_POINT,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
if (l0 == l1
|
|
|
|
&& pre_virtual_p
|
|
|
|
&& post_virtual_p)
|
|
|
|
{
|
|
|
|
/* So pre and post represent two tokens that are present in a
|
|
|
|
same macro expansion. Let's see if the token for pre was
|
|
|
|
before the token for post in that expansion. */
|
|
|
|
unsigned i0, i1;
|
|
|
|
const struct line_map *map =
|
|
|
|
first_map_in_common (set, pre, post, &l0, &l1);
|
|
|
|
|
|
|
|
if (map == NULL)
|
|
|
|
/* This should not be possible. */
|
|
|
|
abort ();
|
|
|
|
|
|
|
|
i0 = l0 - MAP_START_LOCATION (map);
|
|
|
|
i1 = l1 - MAP_START_LOCATION (map);
|
|
|
|
return i1 - i0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return l1 - l0;
|
2001-08-03 01:03:31 +02:00
|
|
|
}
|
2001-08-06 23:07:41 +02:00
|
|
|
|
2001-08-21 23:17:48 +02:00
|
|
|
/* Print an include trace, for e.g. the -H option of the preprocessor. */
|
|
|
|
|
|
|
|
static void
|
2003-06-20 07:51:13 +02:00
|
|
|
trace_include (const struct line_maps *set, const struct line_map *map)
|
2001-08-21 23:17:48 +02:00
|
|
|
{
|
2001-08-22 01:05:12 +02:00
|
|
|
unsigned int i = set->depth;
|
2001-08-21 23:17:48 +02:00
|
|
|
|
2001-08-22 01:05:12 +02:00
|
|
|
while (--i)
|
2001-08-21 23:17:48 +02:00
|
|
|
putc ('.', stderr);
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
fprintf (stderr, " %s\n", ORDINARY_MAP_FILE_NAME (map));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the spelling location of the token wherever it comes from,
|
|
|
|
whether part of a macro definition or not.
|
|
|
|
|
|
|
|
This is a subroutine for linemap_resolve_location. */
|
|
|
|
|
|
|
|
static source_location
|
|
|
|
linemap_macro_loc_to_spelling_point (struct line_maps *set,
|
|
|
|
source_location location,
|
|
|
|
const struct line_map **original_map)
|
|
|
|
{
|
|
|
|
struct line_map *map;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (set && location >= RESERVED_LOCATION_COUNT);
|
|
|
|
|
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
map = (struct line_map*) linemap_lookup (set, location);
|
|
|
|
if (!linemap_macro_expansion_map_p (map))
|
|
|
|
break;
|
|
|
|
|
|
|
|
location =
|
|
|
|
linemap_macro_map_loc_unwind_toward_spelling (map, location);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (original_map)
|
|
|
|
*original_map = map;
|
|
|
|
return location;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If LOCATION is the source location of a token that belongs to a
|
|
|
|
macro replacement-list -- as part of a macro expansion -- then
|
|
|
|
return the location of the token at the definition point of the
|
|
|
|
macro. Otherwise, return LOCATION. SET is the set of maps
|
|
|
|
location come from. ORIGINAL_MAP is an output parm. If non NULL,
|
|
|
|
the function sets *ORIGINAL_MAP to the ordinary (non-macro) map the
|
|
|
|
returned location comes from.
|
|
|
|
|
|
|
|
This is a subroutine of linemap_resolve_location. */
|
|
|
|
|
|
|
|
static source_location
|
|
|
|
linemap_macro_loc_to_def_point (struct line_maps *set,
|
|
|
|
source_location location,
|
|
|
|
const struct line_map **original_map)
|
|
|
|
{
|
|
|
|
struct line_map *map;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (set && location >= RESERVED_LOCATION_COUNT);
|
|
|
|
|
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
map = (struct line_map*) linemap_lookup (set, location);
|
|
|
|
if (!linemap_macro_expansion_map_p (map))
|
|
|
|
break;
|
|
|
|
|
|
|
|
location =
|
|
|
|
linemap_macro_map_loc_to_def_point (map, location);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (original_map)
|
|
|
|
*original_map = map;
|
|
|
|
return location;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If LOCATION is the source location of a token that belongs to a
|
|
|
|
macro replacement-list -- at a macro expansion point -- then return
|
|
|
|
the location of the topmost expansion point of the macro. We say
|
|
|
|
topmost because if we are in the context of a nested macro
|
|
|
|
expansion, the function returns the source location of the first
|
|
|
|
macro expansion that triggered the nested expansions.
|
|
|
|
|
|
|
|
Otherwise, return LOCATION. SET is the set of maps location come
|
|
|
|
from. ORIGINAL_MAP is an output parm. If non NULL, the function
|
|
|
|
sets *ORIGINAL_MAP to the ordinary (non-macro) map the returned
|
|
|
|
location comes from.
|
|
|
|
|
|
|
|
This is a subroutine of linemap_resolve_location. */
|
|
|
|
|
|
|
|
static source_location
|
|
|
|
linemap_macro_loc_to_exp_point (struct line_maps *set,
|
|
|
|
source_location location,
|
|
|
|
const struct line_map **original_map)
|
|
|
|
{
|
|
|
|
struct line_map *map;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (location))
|
2014-02-07 17:42:24 +01:00
|
|
|
location = set->location_adhoc_data_map.data[location
|
|
|
|
& MAX_SOURCE_LOCATION].locus;
|
2012-09-19 21:56:42 +02:00
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
linemap_assert (set && location >= RESERVED_LOCATION_COUNT);
|
|
|
|
|
|
|
|
while (true)
|
|
|
|
{
|
|
|
|
map = (struct line_map*) linemap_lookup (set, location);
|
|
|
|
if (!linemap_macro_expansion_map_p (map))
|
|
|
|
break;
|
|
|
|
location = linemap_macro_map_loc_to_exp_point (map, location);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (original_map)
|
|
|
|
*original_map = map;
|
|
|
|
return location;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Resolve a virtual location into either a spelling location, an
|
|
|
|
expansion point location or a token argument replacement point
|
|
|
|
location. Return the map that encodes the virtual location as well
|
|
|
|
as the resolved location.
|
|
|
|
|
|
|
|
If LOC is *NOT* the location of a token resulting from the
|
|
|
|
expansion of a macro, then the parameter LRK (which stands for
|
|
|
|
Location Resolution Kind) is ignored and the resulting location
|
|
|
|
just equals the one given in argument.
|
|
|
|
|
|
|
|
Now if LOC *IS* the location of a token resulting from the
|
|
|
|
expansion of a macro, this is what happens.
|
|
|
|
|
|
|
|
* If LRK is set to LRK_MACRO_EXPANSION_POINT
|
|
|
|
-------------------------------
|
|
|
|
|
2012-04-26 09:14:01 +02:00
|
|
|
The virtual location is resolved to the first macro expansion point
|
|
|
|
that led to this macro expansion.
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
* If LRK is set to LRK_SPELLING_LOCATION
|
|
|
|
-------------------------------------
|
|
|
|
|
2012-04-26 09:14:01 +02:00
|
|
|
The virtual location is resolved to the locus where the token has
|
|
|
|
been spelled in the source. This can follow through all the macro
|
|
|
|
expansions that led to the token.
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
2012-04-26 09:14:01 +02:00
|
|
|
* If LRK is set to LRK_MACRO_DEFINITION_LOCATION
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
--------------------------------------
|
|
|
|
|
2012-04-26 09:14:01 +02:00
|
|
|
The virtual location is resolved to the locus of the token in the
|
|
|
|
context of the macro definition.
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
If LOC is the locus of a token that is an argument of a
|
|
|
|
function-like macro [replacing a parameter in the replacement list
|
|
|
|
of the macro] the virtual location is resolved to the locus of the
|
|
|
|
parameter that is replaced, in the context of the definition of the
|
|
|
|
macro.
|
|
|
|
|
|
|
|
If LOC is the locus of a token that is not an argument of a
|
|
|
|
function-like macro, then the function behaves as if LRK was set to
|
|
|
|
LRK_SPELLING_LOCATION.
|
|
|
|
|
2014-10-14 16:45:36 +02:00
|
|
|
If MAP is not NULL, *MAP is set to the map encoding the
|
2012-04-26 09:14:01 +02:00
|
|
|
returned location. Note that if the returned location wasn't originally
|
2014-10-14 16:45:36 +02:00
|
|
|
encoded by a map, then *MAP is set to NULL. This can happen if LOC
|
2011-10-25 10:58:54 +02:00
|
|
|
resolves to a location reserved for the client code, like
|
|
|
|
UNKNOWN_LOCATION or BUILTINS_LOCATION in GCC. */
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
source_location
|
|
|
|
linemap_resolve_location (struct line_maps *set,
|
|
|
|
source_location loc,
|
|
|
|
enum location_resolution_kind lrk,
|
|
|
|
const struct line_map **map)
|
|
|
|
{
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (loc))
|
|
|
|
loc = set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
2011-10-25 10:58:54 +02:00
|
|
|
if (loc < RESERVED_LOCATION_COUNT)
|
|
|
|
{
|
|
|
|
/* A reserved location wasn't encoded in a map. Let's return a
|
|
|
|
NULL map here, just like what linemap_ordinary_map_lookup
|
|
|
|
does. */
|
|
|
|
if (map)
|
|
|
|
*map = NULL;
|
|
|
|
return loc;
|
|
|
|
}
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
switch (lrk)
|
|
|
|
{
|
|
|
|
case LRK_MACRO_EXPANSION_POINT:
|
|
|
|
loc = linemap_macro_loc_to_exp_point (set, loc, map);
|
|
|
|
break;
|
|
|
|
case LRK_SPELLING_LOCATION:
|
|
|
|
loc = linemap_macro_loc_to_spelling_point (set, loc, map);
|
|
|
|
break;
|
|
|
|
case LRK_MACRO_DEFINITION_LOCATION:
|
|
|
|
loc = linemap_macro_loc_to_def_point (set, loc, map);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
abort ();
|
|
|
|
}
|
|
|
|
return loc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
Suppose that LOC is the virtual location of a token T coming from
|
|
|
|
the expansion of a macro M. This function then steps up to get the
|
|
|
|
location L of the point where M got expanded. If L is a spelling
|
|
|
|
location inside a macro expansion M', then this function returns
|
|
|
|
the locus of the point where M' was expanded. Said otherwise, this
|
|
|
|
function returns the location of T in the context that triggered
|
|
|
|
the expansion of M.
|
|
|
|
|
|
|
|
*LOC_MAP must be set to the map of LOC. This function then sets it
|
|
|
|
to the map of the returned location. */
|
|
|
|
|
|
|
|
source_location
|
|
|
|
linemap_unwind_toward_expansion (struct line_maps *set,
|
|
|
|
source_location loc,
|
|
|
|
const struct line_map **map)
|
|
|
|
{
|
|
|
|
source_location resolved_location;
|
|
|
|
const struct line_map *resolved_map;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (loc))
|
|
|
|
loc = set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
resolved_location =
|
|
|
|
linemap_macro_map_loc_unwind_toward_spelling (*map, loc);
|
|
|
|
resolved_map = linemap_lookup (set, resolved_location);
|
|
|
|
|
|
|
|
if (!linemap_macro_expansion_map_p (resolved_map))
|
|
|
|
{
|
|
|
|
resolved_location = linemap_macro_map_loc_to_exp_point (*map, loc);
|
|
|
|
resolved_map = linemap_lookup (set, resolved_location);
|
|
|
|
}
|
|
|
|
|
|
|
|
*map = resolved_map;
|
|
|
|
return resolved_location;
|
|
|
|
}
|
|
|
|
|
2012-04-30 13:42:12 +02:00
|
|
|
/* If LOC is the virtual location of a token coming from the expansion
|
|
|
|
of a macro M and if its spelling location is reserved (e.g, a
|
|
|
|
location for a built-in token), then this function unwinds (using
|
|
|
|
linemap_unwind_toward_expansion) the location until a location that
|
2012-05-29 16:53:50 +02:00
|
|
|
is not reserved and is not in a system header is reached. In other
|
2012-04-30 13:42:12 +02:00
|
|
|
words, this unwinds the reserved location until a location that is
|
|
|
|
in real source code is reached.
|
|
|
|
|
|
|
|
Otherwise, if the spelling location for LOC is not reserved or if
|
|
|
|
LOC doesn't come from the expansion of a macro, the function
|
|
|
|
returns LOC as is and *MAP is not touched.
|
|
|
|
|
|
|
|
*MAP is set to the map of the returned location if the later is
|
|
|
|
different from LOC. */
|
|
|
|
source_location
|
|
|
|
linemap_unwind_to_first_non_reserved_loc (struct line_maps *set,
|
|
|
|
source_location loc,
|
|
|
|
const struct line_map **map)
|
|
|
|
{
|
|
|
|
source_location resolved_loc;
|
|
|
|
const struct line_map *map0 = NULL, *map1 = NULL;
|
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (loc))
|
|
|
|
loc = set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
2012-04-30 13:42:12 +02:00
|
|
|
map0 = linemap_lookup (set, loc);
|
|
|
|
if (!linemap_macro_expansion_map_p (map0))
|
|
|
|
return loc;
|
|
|
|
|
|
|
|
resolved_loc = linemap_resolve_location (set, loc,
|
|
|
|
LRK_SPELLING_LOCATION,
|
|
|
|
&map1);
|
|
|
|
|
|
|
|
if (resolved_loc >= RESERVED_LOCATION_COUNT
|
|
|
|
&& !LINEMAP_SYSP (map1))
|
|
|
|
return loc;
|
|
|
|
|
|
|
|
while (linemap_macro_expansion_map_p (map0)
|
|
|
|
&& (resolved_loc < RESERVED_LOCATION_COUNT
|
|
|
|
|| LINEMAP_SYSP (map1)))
|
|
|
|
{
|
|
|
|
loc = linemap_unwind_toward_expansion (set, loc, &map0);
|
|
|
|
resolved_loc = linemap_resolve_location (set, loc,
|
|
|
|
LRK_SPELLING_LOCATION,
|
|
|
|
&map1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (map != NULL)
|
|
|
|
*map = map0;
|
|
|
|
return loc;
|
|
|
|
}
|
|
|
|
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
/* Expand source code location LOC and return a user readable source
|
2011-10-25 10:58:54 +02:00
|
|
|
code location. LOC must be a spelling (non-virtual) location. If
|
|
|
|
it's a location < RESERVED_LOCATION_COUNT a zeroed expanded source
|
|
|
|
location is returned. */
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
expanded_location
|
2011-10-25 10:58:54 +02:00
|
|
|
linemap_expand_location (struct line_maps *set,
|
|
|
|
const struct line_map *map,
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
source_location loc)
|
|
|
|
|
|
|
|
{
|
|
|
|
expanded_location xloc;
|
|
|
|
|
2011-10-25 10:58:54 +02:00
|
|
|
memset (&xloc, 0, sizeof (xloc));
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (loc))
|
|
|
|
{
|
|
|
|
loc = set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus;
|
2014-02-07 17:42:24 +01:00
|
|
|
xloc.data
|
|
|
|
= set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].data;
|
2012-09-19 21:56:42 +02:00
|
|
|
}
|
2011-10-25 10:58:54 +02:00
|
|
|
|
|
|
|
if (loc < RESERVED_LOCATION_COUNT)
|
|
|
|
/* The location for this token wasn't generated from a line map.
|
|
|
|
It was probably a location for a builtin token, chosen by some
|
|
|
|
client code. Let's not try to expand the location in that
|
|
|
|
case. */;
|
|
|
|
else if (map == NULL)
|
|
|
|
/* We shouldn't be getting a NULL map with a location that is not
|
|
|
|
reserved by the client code. */
|
|
|
|
abort ();
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* MAP must be an ordinary map and LOC must be non-virtual,
|
|
|
|
encoded into this map, obviously; the accessors used on MAP
|
|
|
|
below ensure it is ordinary. Let's just assert the
|
|
|
|
non-virtualness of LOC here. */
|
|
|
|
if (linemap_location_from_macro_expansion_p (set, loc))
|
|
|
|
abort ();
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
2011-10-25 10:58:54 +02:00
|
|
|
xloc.file = LINEMAP_FILE (map);
|
|
|
|
xloc.line = SOURCE_LINE (map, loc);
|
|
|
|
xloc.column = SOURCE_COLUMN (map, loc);
|
|
|
|
xloc.sysp = LINEMAP_SYSP (map) != 0;
|
|
|
|
}
|
Linemap infrastructure for virtual locations
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.
From-SVN: r180081
2011-10-17 11:58:56 +02:00
|
|
|
|
|
|
|
return xloc;
|
2001-08-21 23:17:48 +02:00
|
|
|
}
|
2011-10-17 11:59:40 +02:00
|
|
|
|
2011-11-22 17:13:00 +01:00
|
|
|
|
|
|
|
/* Dump line map at index IX in line table SET to STREAM. If STREAM
|
|
|
|
is NULL, use stderr. IS_MACRO is true if the caller wants to
|
|
|
|
dump a macro map, false otherwise. */
|
|
|
|
|
|
|
|
void
|
|
|
|
linemap_dump (FILE *stream, struct line_maps *set, unsigned ix, bool is_macro)
|
|
|
|
{
|
|
|
|
const char *lc_reasons_v[LC_ENTER_MACRO + 1]
|
|
|
|
= { "LC_ENTER", "LC_LEAVE", "LC_RENAME", "LC_RENAME_VERBATIM",
|
|
|
|
"LC_ENTER_MACRO" };
|
|
|
|
const char *reason;
|
|
|
|
struct line_map *map;
|
|
|
|
|
|
|
|
if (stream == NULL)
|
|
|
|
stream = stderr;
|
|
|
|
|
|
|
|
if (!is_macro)
|
|
|
|
map = LINEMAPS_ORDINARY_MAP_AT (set, ix);
|
|
|
|
else
|
|
|
|
map = LINEMAPS_MACRO_MAP_AT (set, ix);
|
|
|
|
|
|
|
|
reason = (map->reason <= LC_ENTER_MACRO) ? lc_reasons_v[map->reason] : "???";
|
|
|
|
|
|
|
|
fprintf (stream, "Map #%u [%p] - LOC: %u - REASON: %s - SYSP: %s\n",
|
|
|
|
ix, (void *) map, map->start_location, reason,
|
|
|
|
(!is_macro && ORDINARY_MAP_IN_SYSTEM_HEADER_P (map)) ? "yes" : "no");
|
|
|
|
if (!is_macro)
|
|
|
|
{
|
|
|
|
unsigned includer_ix;
|
|
|
|
struct line_map *includer_map;
|
|
|
|
|
|
|
|
includer_ix = ORDINARY_MAP_INCLUDER_FILE_INDEX (map);
|
|
|
|
includer_map = includer_ix < LINEMAPS_ORDINARY_USED (set)
|
|
|
|
? LINEMAPS_ORDINARY_MAP_AT (set, includer_ix)
|
|
|
|
: NULL;
|
|
|
|
|
|
|
|
fprintf (stream, "File: %s:%d\n", ORDINARY_MAP_FILE_NAME (map),
|
|
|
|
ORDINARY_MAP_STARTING_LINE_NUMBER (map));
|
|
|
|
fprintf (stream, "Included from: [%d] %s\n", includer_ix,
|
|
|
|
includer_map ? ORDINARY_MAP_FILE_NAME (includer_map) : "None");
|
|
|
|
}
|
|
|
|
else
|
|
|
|
fprintf (stream, "Macro: %s (%u tokens)\n",
|
|
|
|
linemap_map_get_macro_name (map),
|
|
|
|
MACRO_MAP_NUM_MACRO_TOKENS (map));
|
|
|
|
|
|
|
|
fprintf (stream, "\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2011-10-17 11:59:40 +02:00
|
|
|
/* Dump debugging information about source location LOC into the file
|
|
|
|
stream STREAM. SET is the line map set LOC comes from. */
|
|
|
|
|
|
|
|
void
|
|
|
|
linemap_dump_location (struct line_maps *set,
|
|
|
|
source_location loc,
|
|
|
|
FILE *stream)
|
|
|
|
{
|
|
|
|
const struct line_map *map;
|
|
|
|
source_location location;
|
2011-10-25 10:58:54 +02:00
|
|
|
const char *path = "", *from = "";
|
|
|
|
int l = -1, c = -1, s = -1, e = -1;
|
2011-10-17 11:59:40 +02:00
|
|
|
|
2012-09-19 21:56:42 +02:00
|
|
|
if (IS_ADHOC_LOC (loc))
|
|
|
|
loc = set->location_adhoc_data_map.data[loc & MAX_SOURCE_LOCATION].locus;
|
|
|
|
|
2011-10-17 11:59:40 +02:00
|
|
|
if (loc == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
location =
|
|
|
|
linemap_resolve_location (set, loc, LRK_MACRO_DEFINITION_LOCATION, &map);
|
|
|
|
|
2011-10-25 10:58:54 +02:00
|
|
|
if (map == NULL)
|
|
|
|
/* Only reserved locations can be tolerated in this case. */
|
|
|
|
linemap_assert (location < RESERVED_LOCATION_COUNT);
|
2011-10-17 11:59:40 +02:00
|
|
|
else
|
2011-10-25 10:58:54 +02:00
|
|
|
{
|
|
|
|
path = LINEMAP_FILE (map);
|
|
|
|
l = SOURCE_LINE (map, location);
|
|
|
|
c = SOURCE_COLUMN (map, location);
|
|
|
|
s = LINEMAP_SYSP (map) != 0;
|
|
|
|
e = location != loc;
|
|
|
|
if (e)
|
|
|
|
from = "N/A";
|
|
|
|
else
|
|
|
|
from = (INCLUDED_FROM (set, map))
|
|
|
|
? LINEMAP_FILE (INCLUDED_FROM (set, map))
|
|
|
|
: "<NULL>";
|
|
|
|
}
|
2011-10-17 11:59:40 +02:00
|
|
|
|
|
|
|
/* P: path, L: line, C: column, S: in-system-header, M: map address,
|
2011-10-25 10:58:54 +02:00
|
|
|
E: macro expansion?, LOC: original location, R: resolved location */
|
|
|
|
fprintf (stream, "{P:%s;F:%s;L:%d;C:%d;S:%d;M:%p;E:%d,LOC:%d,R:%d}",
|
|
|
|
path, from, l, c, s, (void*)map, e, loc, location);
|
2011-10-17 11:59:40 +02:00
|
|
|
}
|
2011-10-17 11:59:52 +02:00
|
|
|
|
PR preprocessor/58580 - preprocessor goes OOM with warning for zero literals
In this problem report, the compiler is fed a (bogus) translation unit
in which some literals contain bytes whose value is zero. The
preprocessor detects that and proceeds to emit diagnostics for that
king of bogus literals. But then when the diagnostics machinery
re-reads the input file again to display the bogus literals with a
caret, it attempts to calculate the length of each of the lines it got
using fgets. The line length calculation is done using strlen. But
that doesn't work well when the content of the line can have several
zero bytes. The result is that the read_line never sees the end of
the line because strlen repeatedly reports that the line ends before
the end-of-line character; so read_line thinks its buffer for reading
the line is too small; it thus increases the buffer, leading to a huge
memory consumption and disaster.
Here is what this patch does.
location_get_source_line is modified to return the length of a source
line that can now contain bytes with zero value.
diagnostic_show_locus() is then modified to consider that a line can
have characters of value zero, and so just shows a white space when
instructed to display one of these characters.
Additionally location_get_source_line is modified to avoid re-reading
each and every line from the beginning of the file until it reaches
the line number N that it is instructed to get; this was leading to
annoying quadratic behaviour when reading adjacent lines near the end
of (big) files. So a cache is now associated to the file opened in
text mode. When the content of the file is read, that content is
stashed in the file cache. That file cache is searched for line
delimiters. A number of line positions are saved in the cache and a
number of file caches are kept in memory. That way when
location_get_source_line is asked to read line N + 1, it just has to
start reading from line N that it has already read.
libcpp/ChangeLog:
* include/line-map.h (linemap_get_file_highest_location): Declare
new function.
* line-map.c (linemap_get_file_highest_location): Define it.
gcc/ChangeLog:
* input.h (location_get_source_line): Take an additional line_size
parameter.
(void diagnostics_file_cache_fini): Declare new function.
* input.c (struct fcache): New type.
(fcache_tab_size, fcache_buffer_size, fcache_line_record_size):
New static constants.
(diagnostic_file_cache_init, total_lines_num)
(lookup_file_in_cache_tab, evicted_cache_tab_entry)
(add_file_to_cache_tab, lookup_or_add_file_to_cache_tab)
(needs_read, needs_grow, maybe_grow, read_data, maybe_read_data)
(get_next_line, read_next_line, goto_next_line, read_line_num):
New static function definitions.
(diagnostic_file_cache_fini): New function.
(location_get_source_line): Take an additional output line_len
parameter. Re-write using lookup_or_add_file_to_cache_tab and
read_line_num.
* diagnostic.c (diagnostic_finish): Call
diagnostic_file_cache_fini.
(adjust_line): Take an additional input parameter for the length
of the line, rather than calculating it with strlen.
(diagnostic_show_locus): Adjust the use of
location_get_source_line and adjust_line with respect to their new
signature. While displaying a line now, do not stop at the first
null byte. Rather, display the zero byte as a space and keep
going until we reach the size of the line.
* Makefile.in: Add vec.o to OBJS-libcommon
gcc/testsuite/ChangeLog:
* c-c++-common/cpp/warning-zero-in-literals-1.c: New test file.
Signed-off-by: Dodji Seketeli <dodji@seketeli.org>
From-SVN: r206957
2014-01-23 10:13:08 +01:00
|
|
|
/* Return the highest location emitted for a given file for which
|
|
|
|
there is a line map in SET. FILE_NAME is the file name to
|
|
|
|
consider. If the function returns TRUE, *LOC is set to the highest
|
|
|
|
location emitted for that file. */
|
|
|
|
|
|
|
|
bool
|
|
|
|
linemap_get_file_highest_location (struct line_maps *set,
|
|
|
|
const char *file_name,
|
|
|
|
source_location *loc)
|
|
|
|
{
|
|
|
|
/* If the set is empty or no ordinary map has been created then
|
|
|
|
there is no file to look for ... */
|
|
|
|
if (set == NULL || set->info_ordinary.used == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Now look for the last ordinary map created for FILE_NAME. */
|
|
|
|
int i;
|
|
|
|
for (i = set->info_ordinary.used - 1; i >= 0; --i)
|
|
|
|
{
|
|
|
|
const char *fname = set->info_ordinary.maps[i].d.ordinary.to_file;
|
|
|
|
if (fname && !filename_cmp (fname, file_name))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i < 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* The highest location for a given map is either the starting
|
|
|
|
location of the next map minus one, or -- if the map is the
|
|
|
|
latest one -- the highest location of the set. */
|
|
|
|
source_location result;
|
|
|
|
if (i == (int) set->info_ordinary.used - 1)
|
|
|
|
result = set->highest_location;
|
|
|
|
else
|
|
|
|
result = set->info_ordinary.maps[i + 1].start_location - 1;
|
|
|
|
|
|
|
|
*loc = result;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2011-10-17 11:59:52 +02:00
|
|
|
/* Compute and return statistics about the memory consumption of some
|
|
|
|
parts of the line table SET. */
|
|
|
|
|
|
|
|
void
|
|
|
|
linemap_get_statistics (struct line_maps *set,
|
|
|
|
struct linemap_stats *s)
|
|
|
|
{
|
2011-10-18 10:44:49 +02:00
|
|
|
long ordinary_maps_allocated_size, ordinary_maps_used_size,
|
2011-10-17 11:59:52 +02:00
|
|
|
macro_maps_allocated_size, macro_maps_used_size,
|
|
|
|
macro_maps_locations_size = 0, duplicated_macro_maps_locations_size = 0;
|
|
|
|
|
|
|
|
struct line_map *cur_map;
|
|
|
|
|
|
|
|
ordinary_maps_allocated_size =
|
|
|
|
LINEMAPS_ORDINARY_ALLOCATED (set) * sizeof (struct line_map);
|
|
|
|
|
|
|
|
ordinary_maps_used_size =
|
|
|
|
LINEMAPS_ORDINARY_USED (set) * sizeof (struct line_map);
|
|
|
|
|
|
|
|
macro_maps_allocated_size =
|
|
|
|
LINEMAPS_MACRO_ALLOCATED (set) * sizeof (struct line_map);
|
|
|
|
|
|
|
|
for (cur_map = LINEMAPS_MACRO_MAPS (set);
|
|
|
|
cur_map && cur_map <= LINEMAPS_LAST_MACRO_MAP (set);
|
|
|
|
++cur_map)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
linemap_assert (linemap_macro_expansion_map_p (cur_map));
|
|
|
|
|
|
|
|
macro_maps_locations_size +=
|
|
|
|
2 * MACRO_MAP_NUM_MACRO_TOKENS (cur_map) * sizeof (source_location);
|
|
|
|
|
|
|
|
for (i = 0; i < 2 * MACRO_MAP_NUM_MACRO_TOKENS (cur_map); i += 2)
|
|
|
|
{
|
|
|
|
if (MACRO_MAP_LOCATIONS (cur_map)[i] ==
|
|
|
|
MACRO_MAP_LOCATIONS (cur_map)[i + 1])
|
|
|
|
duplicated_macro_maps_locations_size +=
|
|
|
|
sizeof (source_location);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
macro_maps_used_size =
|
|
|
|
LINEMAPS_MACRO_USED (set) * sizeof (struct line_map);
|
|
|
|
|
|
|
|
s->num_ordinary_maps_allocated = LINEMAPS_ORDINARY_ALLOCATED (set);
|
|
|
|
s->num_ordinary_maps_used = LINEMAPS_ORDINARY_USED (set);
|
|
|
|
s->ordinary_maps_allocated_size = ordinary_maps_allocated_size;
|
|
|
|
s->ordinary_maps_used_size = ordinary_maps_used_size;
|
|
|
|
s->num_expanded_macros = num_expanded_macros_counter;
|
|
|
|
s->num_macro_tokens = num_macro_tokens_counter;
|
|
|
|
s->num_macro_maps_used = LINEMAPS_MACRO_USED (set);
|
|
|
|
s->macro_maps_allocated_size = macro_maps_allocated_size;
|
|
|
|
s->macro_maps_locations_size = macro_maps_locations_size;
|
|
|
|
s->macro_maps_used_size = macro_maps_used_size;
|
|
|
|
s->duplicated_macro_maps_locations_size =
|
|
|
|
duplicated_macro_maps_locations_size;
|
|
|
|
}
|
2011-11-22 17:13:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
/* Dump line table SET to STREAM. If STREAM is NULL, stderr is used.
|
|
|
|
NUM_ORDINARY specifies how many ordinary maps to dump. NUM_MACRO
|
|
|
|
specifies how many macro maps to dump. */
|
|
|
|
|
|
|
|
void
|
|
|
|
line_table_dump (FILE *stream, struct line_maps *set, unsigned int num_ordinary,
|
|
|
|
unsigned int num_macro)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (set == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (stream == NULL)
|
|
|
|
stream = stderr;
|
|
|
|
|
|
|
|
fprintf (stream, "# of ordinary maps: %d\n", LINEMAPS_ORDINARY_USED (set));
|
|
|
|
fprintf (stream, "# of macro maps: %d\n", LINEMAPS_MACRO_USED (set));
|
|
|
|
fprintf (stream, "Include stack depth: %d\n", set->depth);
|
|
|
|
fprintf (stream, "Highest location: %u\n", set->highest_location);
|
|
|
|
|
|
|
|
if (num_ordinary)
|
|
|
|
{
|
|
|
|
fprintf (stream, "\nOrdinary line maps\n");
|
|
|
|
for (i = 0; i < num_ordinary && i < LINEMAPS_ORDINARY_USED (set); i++)
|
|
|
|
linemap_dump (stream, set, i, false);
|
|
|
|
fprintf (stream, "\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (num_macro)
|
|
|
|
{
|
|
|
|
fprintf (stream, "\nMacro line maps\n");
|
|
|
|
for (i = 0; i < num_macro && i < LINEMAPS_MACRO_USED (set); i++)
|
|
|
|
linemap_dump (stream, set, i, true);
|
|
|
|
fprintf (stream, "\n");
|
|
|
|
}
|
|
|
|
}
|