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

[Per Bothner]

Geert Bosch wrote:

> There seems to be a severe abstraction inversion here. It's none
> of the back end's business how the front end parses source files.
> For all it cares, the front end might parse files back-to-front.

Even so it presumably would read tokens front-to-back.

> Also, the whole notion of "include" nesting is front end related.
> Ada, for example, has no notion of includes, but uses a module
> system. How this is represented in source files is a choice of
> the front end implementation, and the back end has nothing to
> do with it.

The include-file tracking is a relatively cheap bonus feature
of the line-map library" - just ignore it for Ada.

> It seems to me that the "locus" should be an opaque 32-bit type,
> with accessor functions to retrieve file, line and column information.
> Front ends implement these accessor functions, and the back end
> doesn't care how the information is stored.

It certainly is possible to add just an abstraction layer - I just
don't see the point.

> The C front ends, and maybe others, can use the new mapped location
> approach using the interface you described to create a new locus.
> Front ends for which this approach is not a good fit, can implement
> the much simpler accessor functions for loci.

I haven't seen any real reason why the line_table mapping would be a
poor fit for Ada, or why there would be any problem (performance or
otherwise) with using it for Ada.

We use the line_table for C/C++/ObjC, Java, and Fortran without problem.
I don't see why Ada would have any problem.

> For Ada, processing a single compilation unit might require parsing 
> hundreds
> of files.

Just like C, C++, and Java.

  This is much more common than with other languages, since Ada
> allows
> cross-unit inlining, which requires not only parsing all specifications, 
> but
> also bodies of units with potentially inlined subprograms.

Like C++ and Java.

> Apart from this, it is bad practice to litter the parser with calls into
> the back end to produce duplicate line number information.

I don't know why you refer to the "back end".  line-map.[ch] is a self-
contained "library" that was originally used for cpplib, which is part
of the C/C++ *front-ends*.  There are no "back-end" calls.

> I think the ideal approach is to view the locus as private to the front 
> ends.
> Then we just use the Ada "Sloc" as locus and provide the necessary
> functions to map this locus to file, line, column information.

This slightly complicates 90% of the compiler (trees, rtl, debugging,
error handling) adding a extra level of indirection because you don't
want to add 10 lines to the Ada front-end.  That doesn't seem like a
good tradeoff to me.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/