This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Better GCC diagnostics
2008/8/20 Arnaud Charlet <charlet@adacore.com>:
>> Not just that, probably Fortran/Ada are already duplicating stuff that
>> is in libcpp or they are implementing their own version of stuff that
>> C/C++ are lacking (caret diagnostics? character encodings?).
>
> Well, clearly, the preprocessor and handling of #include is very
> C/C++ specific, and not used by Ada or Fortran.
Both Ada and Fortran are linked with libcpp.a.
> As for diagnostics, Ada does use its own mechanism, mainly because it's
> much more powerful than the one in libcpp, and handles e.g. multiple
> locations related to cascaded generic package instantiations (C++ templates),
> as well as many other goodies already described by Robert is previous messages.
Even if you do not use line-map.o, the middle-end does, so you still
have the duplication.
> It has also handled column info from day one (and we would not want any
> of the e.g. -fshow-column stuff: why would you *not* want to display
> column information ? :-)
Yes, why?
> So from GNAT's point of view, what's the point in duplicating all this
> work done and written in Ada in another less capable language (which would also
> make it more painful for GNAT developers to use), in particular if this
> capability is only available in very recent GCC versions.
The point is that other front-ends would be able to use it. And
non-Ada developers would be able to fix it and extend it. Moreover,
even if GNAT won't use it, moving all this out of libcpp and making it
modular would allow to link only to the things that you really need.
Finally, the middle-end is using it anyway, so gnat is using it.
Cheers,
Manuel.