[Ada] Fix bogus noreturn warning

[Manuel López-Ibáñez]

On 27 June 2010 18:21, Steven Bosscher <stevenb.gcc@gmail.com> 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 problem is that things are so much entangled now, that it really
> is just a matter of disentangling the worst first, then define
> something and move to match it.

I see. Still, the most important part is "define something". I guess
also the most difficult.

> The silly thing is, it is even mis-named because it doesn't look at
> blocks but at statement lists.  So it could live in tree.h, or
> tree-iterator.h perhaps. Not basic-block.h or gimple.h because it
> doesn't have anything to do with those.

Somehow, I am not surprise to hear this. ;-)

>> The above are reasons why I think that the headers cleanup, despite
>> being something eventually necessary, it is pointless to do before
>> fully specifying the boundaries between modules. Without that, someone
>> will come and undo your work. Once the boundaries and dependencies are
>> defined, then moving things around and cleaning up the headers
>> dependencies is a fairly mechanic task that people will be "forced" to
>> do whenever they want to use a function that is currently misplaced.
>
> This is how things would be done in an environment with strong
> leadership and a common design plan. But this is not how I would
> describe the GCC community. You wouldn't be able to force anyone to do
> anything, and you have to move things around before you can enforce a
> boundary. This is what I have tried with the RTL headers (and note:
> the 3 places that violate this have not received any attention to
> finish the job).

I don't think you can force anyone to do something, but if somewhere
it is written that tree-flow.h cannot be included in FEs, then you
won't convince anyone to fix the existing cases but you will give a
reason to reviewers to reject a patch and ask for an alternative
version (or to fix the misplaced functions). Of course, we know that
maintainers often break their own rules (no testcases, no comments,
etc.). If the boundary was even stronger (e.g., to include tree-flow.h
in the FE you would need to modify the "tree" module), then FE
maintainers will need middle-end permission to break the boundaries.

Cheers,

Manuel.