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 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 [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
