This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ada, treelang needs to be converted to --enable-mapped-location


Richard Kenner wrote:

So indeed I suspect the changes are tiny, but would appreciate a little more
details about what needs to be done.

* Before defining builtins do: linemap_add (&line_table, LC_ENTER, false, main_input_filename, 1); linemap_add (&line_table, LC_RENAME, false, "<built-in>", 0);

* When starting to parse a new source file do:
  linemap_add (&line_table, LC_ENTER, false, filename, 1);
but if it's the first/main source file it's probably better to
use LC_RENAME instead of LC_ENTER, since otherwise the code will
think that filename is "included" from <built-in>.  (The compile
server branch tries to do things a little differently, btw.)

* When done with a source file:
  linemap_add (&line_table, LC_LEAVE, 0, NULL, 0);
(Including a source file should not use an LC_LEAVE; just an
LC_ENTER of the included file, and then an LC_LEAVE when we
return to the including file.)

* At the start of each source line:
  source_location line_start_loc
    = linemap_line_start (&line_table, lineno, max_col_hint);
You can optionally:
  input_location = line_start_loc;
The lineno is the current 1-origin number of the new line.
The max_col_hint can be 1 if you're not keeping track of
column numbers, or some higher number if you are.  I used 120
in the Fortran front end, as that is less than 2^7.  I'd have
to look at the code to see what the limit is before we need an
extra bit, but 125 is presumably safe.

* Whenever you want a source_location with a column number, do
(after a linemap_line_start for the current line):
  LINEMAP_POSITION_FOR_COLUMN (loc, &line_table, col);
Here 'loc' is an lvalue (e.g. input_location) that gets a
source_location for column 'col' of the current line.

* In the current implementation, neither column numbers or line
numbers have to increase monotically, but it's probably a good
idea if they are.  It is also best to allocate source_location
numbers in a single pass:  There is no intelligence in terms of
trying to reuse previous line_map entries (except for the current
/most recent line_map).  Also, expand_location and other functions
that call linemap_lookup use a binary search, which is ok, but
there is obviously some overhead compared to the old mechanism
of just getting a filename or line field from a location_t pair.
So it is good to avoid needless round-trips between source_location
and expanded filename/line[/column] values.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]