problem in gcc (lib) headers __BEGIN_DECLS & traceback-incomplete
Jonathan Wakely
jwakely.gcc@gmail.com
Wed Mar 8 02:04:00 GMT 2017
On 8 March 2017 at 01:54, L A Walsh <gcc@tlinx.org> 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.
More information about the Gcc-help
mailing list