clattner at apple.com
Sun Feb 10 23:01:58 PST 2008
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. In this specific case, I think that
turning a function into a pointer to function is unlikely to do that
That said, Steve's idea might still be a good one. In what other
cases can a struct decl be marked erroneous?
More information about the cfe-dev