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

[Robert Dewar <dewar at gnat dot com>]

Robert Dewar wrote:

> > My proposal is basically to take the view that source_location is an 
> > unsigned
> > int that's an opaque datatype used to encode a (file, line column) 
> > triple.
> > This datatype can either be defined in the front end (in which case it
> > provides a language hook to produce that triple from the encoding) or 
> > it can
> > use routines provided in line-map.c to generate the encoding.

I did a bit more rummaging in the Ada front end. It is certainly not the
case that the Ada front end regards this type as opaque. The following
assumptions are fairly strongly embedded.

1. The values representing the column positions of a single line are
consecutive integer values, so it is fine to do arithmetic, e.g. to
compute the right column location for an error message that is to be
issued in the middle of a token, e.g. a character in a string literal
that is not in the subtype:

     1. package q is
     2.    type r is ('a', 'b', 'c');
     3.    type m is array (integer range <>) of r;
     4.    s : m:= "abababdcbcbcb";
                          |
        >>> character not defined for type "r" defined at line 2

     5. end q;

2. If two values represent source locations in the same source file, then
they are strictly ordered, so that a comparison of source locations
indicates ordering in the file.

3. The Sloc values in GNAT are signed. THe negative values are used to
indicate special locations (No_Location, Standard_Location,
Standard_ASCII_Location, System_Location), and the code uses
range tests to test for special locations.

There may be other assumptions, but these are the ones that are for
sure present.

It would be possible to eliminate all such non-opaque
assumptions, and indeed it might be a good idea to do so, but it
is not a trivial job.

Of course the back end could regard it as opaque, but that's only
part of the story. The above issues would definitely have to be
addressed if there was a consideration of changing the representation
in GNAT. The fairly elaborate representation of source locations
was part of the original design of GNAT 14 years ago since error
message placement was one of the original areas we concentrated
on, and I fear it has at this stage assumptions about the basic
form of these values, which has not changed significantly in
this time period, are fairly strongly embedded.

At the least I will investigate this further, and

  a) document these assumptions that are being made

  b) at least gradually try to eliminate them

Making Source_Ptr a private type of package Sinput would
be desirable, but that is for sure quite a bit of work!