2008/8/20 Tom Tromey <[EMAIL PROTECTED]>:
>>>>>> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> If I ever get the time, I would like to abstract our line-map
> Manuel> implementation within a "location_manager" object and API but
> Manuel> I don't think this conflicts directly with your work.
>
> I am curious to know how this would be different from what we have
> now.
>
> I think the line-map API is rather ugly, personally, but it seems to
> me that a "struct line_maps" is essentially a location manager object.
It is essentially. However, all the internal things are exposed all
over the place for no good reason.
This is in gcc/c-lex.c
/* #define callback for DWARF and DWARF2 debug info. */
static void
cb_define (cpp_reader *pfile, source_location loc, cpp_hashnode *node)
{
- const struct line_map *map = linemap_lookup (line_table, loc);
- (*debug_hooks->define) (SOURCE_LINE (map, loc),
+ (*debug_hooks->define) (location_source_line (location_manager, loc),
(const char *) cpp_macro_definition (pfile, node));
}
This is in tree.h
-expanded_location
-expand_location (source_location loc)
-{
- expanded_location xloc;
- if (loc == 0)
- {
- xloc.file = NULL;
- xloc.line = 0;
- xloc.column = 0;
- xloc.sysp = 0;
- }
- else
- {
- const struct line_map *map = linemap_lookup (line_table, loc);
- xloc.file = map->to_file;
- xloc.line = SOURCE_LINE (map, loc);
- xloc.column = SOURCE_COLUMN (map, loc);
- xloc.sysp = map->sysp != 0;
- };
- return xloc;
-}
+#define expand_location(LOC) location_expand (location_manager, (LOC))
+
Moreover, the location_manager probably should be separated from CCP.
If we want to implement re-opening files and reading strings given
locations, then opening/reading files should also be moved out of CCP
to its own module/namespace/object.
Cheers,
Manuel.
