[cfe-dev] Type>>isObjCInterfaceType() blows up

Steve Naroff snaroff at apple.com
Tue Apr 22 17:30:50 PDT 2008


Interesting. I'm sure you're not the last person to be bitten by this...

Chris, do you think the API should try and protect against this type  
of mistake?

Seems like we should have a clang::ASTContext::Create() function that  
removes the need for a public constructor.

snaroff

On Apr 22, 2008, at 4:17 PM, Emerson Murphy-Hill wrote:

> Solution:
> I was using ASTParser.cpp, which allocated an ASTContext on the stack:
>
>   ASTContext Context(PP.getSourceManager(), PP.getTargetInfo(),
>                      PP.getIdentifierTable(), PP.getSelectorTable());
>
> When I returned from the method, the ASTContext gets destroyed,  
> after which I wasn't getting valid types.  Changed the line in  
> ASTParser to allocate the ASTContext on the heap:
>
>   ASTContext* Context = new ASTContext(PP.getSourceManager(),  
> PP.getTargetInfo(),
>                      PP.getIdentifierTable(), PP.getSelectorTable());
>
> And isObjCInterfaceType works as expected. Thanks to Ted, Chris, and  
> Steve for helping me out with this.
>
> -e
>
> On Apr 18, 2008, at 10:55 AM, Chris Lattner wrote:
>>
>> On Apr 18, 2008, at 10:52 AM, Emerson Murphy-Hill wrote:
>>
>>> Ahoy!
>>>
>>> I'm trying to determine the SourceLocation of an Objective-C  
>>> instance variable's type, if there is one.  This seemed like a  
>>> reasonable way to start:
>>>
>>>     clang::ObjCIvarDecl* iVar = ... //your ivar here...
>>>     clang::Type* t = iVar->getType().getTypePtr();
>>>     t->isObjCInterfaceType();
>>>
>>> Unfortunately, I get an EXC_BAD_ACCESS on the final line.  For the  
>>> test case I'm working on, I would have expected it to simply  
>>> return false, since my ivar is an int.
>>>
>> What does iVar->getType().dump()  print?
>>
>> Does 'iVar->getType()->isObjCInterfaceType()' work?
>>
>> -Chris
>
> _______________________________________________
> 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/20080422/f6bbf5a0/attachment.html>


More information about the cfe-dev mailing list