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

[David Blaikie]

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))