> My point is that if the rest of the compiler extends diagnostics.c to
> handle caret and ranges and all other features, Ada would need carry
> all that around even if gnat has its own diagnostics machinery. But
> perhaps that is OK.

Certainly OK, what possible (noticeable) issue would you foresee ?

> I am not trying to force anything just make you
> aware of the situation.

Well, it's not like there's a choice anyway. As Robert and myself explained,
GNAT's machinery is much more powerful in terms of diagnostic compared to
libcpp (or even compared to what's planned), and this
machinery is used in other non GCC contexts anyway, so has its own
life cycle and raison d'être.

> I see that as very unrealistic, GCC development is already complex
> enough, so we will have to live with the duplication.

That was of course a semi joke :-) Only semi because it would make
a lot of sense to write a code generator from scratch in Ada, but of
course it does not make much sense to rewrite GCC in Ada.

> I just wanted to
> make you notice that even if location_t is moved out of libcpp, GNAT
> will still link with diagnostic.c and whatever other diagnostics
> features that will be implemented. The burden of the duplication would
> be on GNAT executable, the other front-ends do not carry GNAT's code.
> Probably the effect of it is negligible, anyway.

Right, effect is clearly negligible, if noticeable at all.

> Again, my point is that even if GNAT has all these features already,
> GNAT should be interested in this since it means moving stuff out of
> libcpp which will allow to break that dependency. C/C++ could very
> well implement caret diagnostics and everything else within libcpp, so
> the dependency of GNAT with libcpp would be actually harder to break.
> My fear is that if the other FEs do not care about this issue "because
> we have it already", then this is exactly what will happen.

Well, if other GCC developers do not see the obvious advantages in
splitting libcpp in several logical pieces, then so be it, what can I
say.

Arno

Reply via email to