Re: integral location_t

[Per Bothner <per at bothner dot com>]

Richard Henderson wrote:
> Would those that are interested in this representational change
> let me know what requirements they were thinking of from a library or 
> interface perspective?

Just to make sure there are no misunderstandings, I assume what we're
talking about is achieving:
  typedef fileline location_t;
where fileline is as defined in line-map.h?
(And then we might remove either fileline or location_t as
there is little point in having two names for the same thing.)

I would first fix the code so that fileline is used consistently.
I.e. (during the transition period at least) change fileline to:
  typedef struct ( unsigned int cookie; } fileline;
Add appropriate accessor macros and constructor macros (for
example a macro to replace (fileline)0), and fix all the places
that break.

The next step is to try typedef fileline location_t, and see what
breaks there.

Nathan Sidwell wrote:

> *) globally unique line-ids -- no context is needed for the
> line-id -> file:line mapping

In practice we have that, since (I believe) only one struct line_maps
is created, and we can just add a global pointer to it.  (Just like
the parse_in global points to the unique cpp_reader instance.)

> *) ability to obtain a line-id corresponding to filename without line
> number (whether this maps directly from line-id -> line_id or from
> filename to line-id, I'm not sure, I suspect the former might be better).

Would being to have use "line number == 0" for any file work?  I don't
know if that works.

> *) ability to create new line-id's 'off the end' of the main input file(s)
> (so artificial functions such as static_initialization..., have unique
> line numbers)

You can do that - you can call linemap_add at any time.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/