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 [EMAIL PROTECTED] http://per.bothner.com/
