r208015 - Build debug info for ObjC interface types at the end of the translation unit to ensure all ivars are included.

[Jordan Rose]

On May 5, 2014, at 16:53 , David Blaikie <dblaikie at gmail.com> wrote:

> On Mon, May 5, 2014 at 4:49 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> On May 5, 2014, at 16:46 , David Blaikie <dblaikie at gmail.com> wrote:
>> 
>> On Mon, May 5, 2014 at 4:38 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> @interface is a definition of an ObjC class, but it doesn't contain all the
>> ivars. @implementation can also contain ivars, but it's not in the
>> redeclaration chain for the @interface/@class. Is this going to mess things
>> up at all?
>> 
>> 
>> If the @implementation isn't in the redeclaration chain of the
>> @interface, then I'm not sure how those two entities would be related
>> in the debug info... but a cursory test (a simple @implementation
>> placed at the end of the test case, containing a single @public int)
>> does cause the debug info to have that member variable included in the
>> debug info...
>> 
>> Is that the sort of case you were concerned about?
>> 
>> 
>> I guess so. I don't know enough about debug info generation to know what's
>> important here, but this section scared me:
>> 
>> A side benefit is that we also don't need the CompletedTypeCache
>> anymore. Just rely on the declaration-ness of a type to decide whether
>> its definition is yet to be emitted.
>> 
>> 
>> ...since an ObjCInterfaceDecl is considered a definition long before we may
>> have seen all the ivars.
> 
> Ah, sorry - implementation details omitted from the commit message.
> For ObjCInterfaces, with this patch, we now defer generating the debug
> info for the definition until the end of the translation unit in all
> cases. So we'll get whatever ivars, properties, etc, are visible at
> that point.
> 
> (previously we would keep rebuilding the debug info for ObjCInterfaces
> whenever we would see a use of the type again - this meant that in
> some cases where we didn't see a debug-info-worthy use of the type
> (eg: a variable, function parameter definition, etc) we missed some
> ivars)
> 
>> (In fact, you can only be sure you've seen all the
>> ivars if the TU has an @implementation in it.)
> 
> Yeah, that bit I can't speak to - the type will appear different in
> different translation units.
> 
> (does an @interface need an @implementation? Will the @implementation
> necessarily have all the @interfaces preceeding it in the source file?
> If so, we could probably reduce debug info size here by only emitting
> a declaration for any @interface usage, and only emitting the
> definition in translation units with the @implementation (this is like
> the other -flimit-debug-info/-fno-standalone-debug optimizations
> (which are currently disabled on darwin for a few reasons), so only
> applies if you're compiling the whole program - not just one
> file/library))

Yes, it looks like the @implementation can't have any additional class extensions after it (and of course it needs the main class interface before it as well). There are cases when an @interface doesn't have an @implementation, where you're really using it as more of a protocol than a class, but they're rare and I don't think it would make sense to access ivars in that case.

Jordan