On 8 March 2017 at 01:54, L A Walsh <gcc@xxxxxxxxx> wrote:
> Jonathan Wakely wrote:
>>
>> Because it's valid to do:
>> struct X {
>> #include "foo.h"
>> };
>> Or even:
>> struct Y {
>> #include "bar.h"
>> where the closing brace is in bar.h
>>
>> So the compiler can't give an error before the include, because the
>> header might provide the closing brace.
>
> ---
> Personally, I would regard those cases as
> "less likely" than not, but I admit to being barely (if
> that much) at the "above average" level of C++ familiarity.
>
> Would it not be possible to have
> some switch that would "assume" control-structures don't
> cross included boundaries and could then supply a more helpful
> diagnostic? I.e. the default could stay as is, but for those
> who try not to have control-structs cross file-boundaries, such diagnostics
> are more than a bit "obscure"...
>
> Now that I know about the problem, I can know to check forward as
> well as backward from an error, but in some
> cases, the forward error may be sufficiently far ahead as
> to be rather difficult to find -- or, as in my original make
> log -- completely unlisted due to other non-related errors
> (no related in the sense that they don't tell me where the
> original problem is located).
>
> Would such a switch be possible for projects that could
> benefit by such a switch?
No, it would be better to just improve the diagnostics using some heuristics.
Simply issuing an error whenever a block isn't closed before a header
would not be conforming, but when the compilation fails anyway the
compiler could check if it happened and say something about it in the
errors.
