converting Ada to handle USE_MAPPED_LOCATION

[Per Bothner]

Geert Bosch wrote:
> Of the three proposals:
> 
>> [...]
>> The ideal solution I think is for Ada to use line-map's 
>> source_location for Sloc in its lexer.
>> [...]
>> translate Sloc integers to source_location
>> when we translate the Ada intermal format to Gcc trees.
>> [...]
>> the location_t in the shared Gcc should be a language-defined opaque 
>> time,
>> and have language call-backs.
> 
> 
> The first one really is out for the Ada maintainers, as this would couple
> the front end far too tightly to the back end

Ok.

> and lose the nice property 
> that the exact same front end sources (excluding the few C files for tree 
> conversion) > can be used for any GCC back end from 2.8.1 to 4.1

Does this help with boostrapping?  Otherwise, I'm not sure why this is
important.

But anyway, I'm not going to push for this approach.

> The second one wouldn't be my preferred choice, as it adds complexity 

I think this solution is *less* complex than your preferred solution.
A simple translaton can be done in just a few lines of code, which
are localized to a single file - maybe a single function.  (Adding a
linemap_get_location as I suggested is not strictly needed, but is
probably a good idea.)  Making location_t an opaque type seems to
have a lot more ramifications, including adding language hooks and
making sure they're used where needed.

 > for no gain,

I think call-backs are generally to be avoided.  They make the
system more fragile and less flexible.

Consider a hypothetical Gcc that would allow opimizing modules
from multiple languages.  After inlining, you might have tree
nodes and rtl from either C or Ada, all mixed together.  In that
environment a language-dependent opaque type isn't going to work;
locations have to be translated to a common representation.

 > but because the code can remain localized to the few C files
> interfacing the front end to the back end, this would be acceptable.

Good.

> The last would be far preferred, as it would not tie in front ends so
> much to the back end,

Translating locations at the same time you translate to generic tree
nodes doesn't seem to involve any extra tying.

> As it both seems easiest to implement,

I suspect not.  Simple-seeming changes can end up being quite a pain
to implement when multiple modules are involved.  Just look at Zack's
recent work to clean up version number management.

> and cleanest.

Of course that's in the eye of the beholder.  I think a local translation
is cleaner and more robust/safer than a global opaque type/call-back.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/