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

[Geert Bosch]

On Sep 30, 2004, at 16:02, Per Bothner wrote:
>> ake any difference for the compiler. If it would,
>> that clearly would illustrate that this would create a tight coupling
>> between the front end and the back end. If 90% of the compiler is 
>> aware
>> of the details of the implementation of how locations are stored, that
>> means there is something very wrong in the design.
>
> No, most of the compiler does not need to know the details of how
> locations are stored.
>
> However, if we're to follow your suggestion (as I take it), we
> need two typedefs:
> (a) source_location int as managed by libcpp/line-map.c and used by
> libcpp.
> (b) a different abstract typedef that be used in most of the gcc,
> and whose "meaning" would be defined by language front-ends.  It
> would be defined as (a) in most front-ends, but not Ada.
>
> Accessor macros/functions like DECL_SOURCE_LINE would continue
> to be defined in terms of DECL_SOURCE_LOCATION and LOCATION_LINE.
> However, LOCATION_LINE would become a call-back to a language
> front-end function.

Essentially a) is a special case of b). The back end uses the simple
interface of accessor functions as you describe above. Front ends
can build a mapping using line-map.[ch] and then use its definitions
of these accessor macros, or use its own mapping.

As I understand, Fortran also has a private line map already and may
not require the overhead of maintaining a duplicate data structure.
>
> I think these changes would a add an small extra level of complication
> and confusion.  It's minor and managable, but it is an extra call-back
> interface, which are in principle to be avoided.

As I see it, the interface between front end and back end now
only consists of the few simple accessor functions/macros,
instead of the much, much more complicated line-map.h interface.
If you look at all dependencies between front end and back end
as a graph, the goal is to be able to partition this graph with
cutting as few edges as possible.

You'll see this effect also in Makefile dependencies: back end files
may call the LOCATION_LINE callback, but will not depend on 
line-map.[ch].

> It is also possible to make the line_maps type extensible by putting
> function (method) pointers in the structure, but that also seems
> unnecessary generalization at this point.
>
> Bottom line: you're going to have a hard time convincing people to
> make this change for sake of Ada, given that it's a minor extra
> conversion step for Ada.  Plus given the historical frustrations
> we've had with gnat means we're not going to bend over backwards to
> be optimal for Ada if it complicates the rest of the compiler.

As explained above (and I'll elaborate further in a subsequent email),
I think the above change makes for a much cleaner interface between
front ends and back ends. Having a clean and simple interface will
free you from having to consider Ada in the future when you make
changes to line-map.

   -Geert