Re: [Ada] Fix bogus noreturn warning

[Manuel López-Ibáñez <lopezibanez at gmail dot com>]

On 27 June 2010 20:03, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sun, 27 Jun 2010, Manuel López-Ibáñez wrote:
>
>> I really appreciate what you are trying to do but I insist once more
>> that the ideal interface should be first defined somewhere for people
>> to read, and then start moving things around to match it. The other
>
> I would strongly advocate incremental development in this area as in
> others. ?Small patches can be made that improve modularity in one area

You do not need any patch to define what and what not should be
included by other parts of the compiler. I am asking for that. A
simple question: what headers should and should not be included
(ideally) by FEs?

> without needing a much larger design for what the interfaces will end up
> looking like. ?It is not necessary to work out the issues with a later
> interface change in order to implement an earlier change. ?I didn't need
> to work out how toplev.h and toplev.c should end up getting split up to
> move diagnostics functions to diagnostic-core.h, nor does anyone need such
> a design to change individual files including toplev.h to include
> diagnostic-core.h instead if that's all they needed from toplev.h (or more
> generally to remove unnecessary #includes and fix cases where header A is
> only included for declarations in header B that is included by A).

I think the point is not that a header file is necessary or
unnecessary. If the function that you need is declared in that header,
then one can always make the case that the header *is* necessary. The
point is that it is the wrong header to include. Now, where is the
definition of wrong? That is a design.

I think your example is too simple: It is clear that including
toplev.h to get diagnostics functions is something odd. There is a
loosely defined diagnostic "module" and toplev.h would be a weird
interface for it.

In this case, is tree-low.h the right interface of gimple-low.c for
FEs? Well, it seems it is not clear at all.

In any case, since toplev.h still includes diagnostic-core.h, nothing
prevents anyone to add toplev.h just to get error().

> Working out the ideal interface means understanding what all the
> unexpected interactions are between different parts of the compiler. ?I
> claim that to discover such an interaction in practice you generally need
> to try to remove what looks like an inappropriate include and thereby find

First you need to define what is an inappropriate include. I don't
think this is generally known. And, if it is known, it is ignored in
favor of existing practice, which ends up undoing the modularization
work.

Cheers,

Manuel.