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


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/


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