[cfe-dev] Type::isIncompleteType()...

[Devang Patel]

On Feb 10, 2008, at 11:01 PM, Chris Lattner wrote:

> On Feb 10, 2008, at 9:12 PM, Neil Booth wrote:
>> $ ./cfe /tmp/bug.c
>> "/tmp/bug.c", line 3: error: members may not have function type
>> int foo();
>>     ^
>>
>> 1 error found compiling "/tmp/bug.c".
>>
>> I don't think it necessarily makes sense to expect extra diagnostics
>> in any particular situation; once something is erroneous there are
>> many reasonable recovery strategies.  I think my cfe just ignores
>> the foo declaration as if it didn't exist, for example.  Another
>> quite reasonable strategy would be to have a member foo in the
>> structure but flag it erroneous; this would mean uses of foo wouldn't
>> get diagnostics about no such member.
>
> In this specific case (a single malformed field in a struct) I agree
> with Neil: it's best to just recover by dropping that one field decl,
> or change it into a decl with a valid type (in the case of function,
> make it a pointer to function) which is probably even better.  In
> certain parts of type analysis we try really hard to turn an erroneous
> type into a valid one.
>
> As everyone knows, there is a tradeoff here: the more you try to
> "infer" what the user meant, the more likely it is that your guess can
> trigger a cascade of errors.

.. which is not very useful to user. Yes, Steve's idea of reporting  
two error is good in this example. Even better solution is to clearly  
state that 2nd error is dependent on 1st error.

>  In this specific case, I think that
> turning a function into a pointer to function is unlikely to do that
> though.
>
> That said, Steve's idea might still be a good one.  In what other
> cases can a struct decl be marked erroneous?
>
> -Chris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-
Devang