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

Steve Naroff snaroff at apple.com
Sun Feb 10 20:07:10 PST 2008

On Feb 10, 2008, at 7:13 PM, Ted Kremenek wrote:

> On Feb 10, 2008, at 6:35 PM, Steve Naroff wrote:
>> Folks,
>> Do you think it makes sense for Type::isIncompleteType() to return
>> true when the Tag definition is invalid?
> I guess so.  From the standard (6.2.5):
> "... incomplete types (types that describe objects but lack  
> information needed to determine their sizes). "
> I guess it depends on what clients expect.  Another way to look at  
> this is that a bad tag definition doesn't really type check at all;  
> it's a bogus definition, and doesn't define any kind of type,  
> including an incomplete one.  It's probably safer to have clients  
> believe that a bad tag definition has an incomplete type, and then  
> check *why* it is an incomplete type by interrogating the TagDecl.

I tend to agree with you. If we make this change, the code below will  
result in 2 errors. Note that both EDG & GCC only produce 1 error (the  
first one). From my perspective, not flagging the 2nd error is  
incorrect (though it could lead to some noisy diagnostics, I guess).

Neil, does your cfe produce 1 or 2 diagnostics for the following test  


[steve-naroffs-imac:tools/clang/test] snaroff% cat xx.c
struct S {
   int a;
   int foo();

struct S s;

[steve-naroffs-imac:tools/clang/test] snaroff% ../../../Debug/bin/ 
clang xx.c
xx.c:3:7: error: field 'foo' declared as a function
   int foo();
xx.c:6:10: error: variable has incomplete type 'struct S'
struct S s;
2 diagnostics generated.

>> For example...
>>   case Tagged:
>>      // A tagged type (struct/union/enum/class) is incomplete if the
>> decl is a
>>      // forward declaration, but not a full definition (C99  
>> 6.2.5p22).
>> -    return !cast<TagType>(CanonicalType)->getDecl()->isDefinition();
>> +    TagDecl *TD = cast<TagType>(CanonicalType)->getDecl();
>> +    return !TD->isDefinition() || TD->isInvalidDecl();
>> Since this predicate is fairly low-level, I wanted to get some
>> feedback...
>> snaroff
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080210/761e435b/attachment.html>

More information about the cfe-dev mailing list