[RFC] Warning for large Objective C runtime encodings (-Wobjc-encodings-larger-than=)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Warning for large Objective C runtime encodings (-Wobjc-encodings-larger-than=)

Richard Smith via cfe-dev
Hey esteemed colleagues,

We recently noticed that we were generating some incredibly large Objective C runtime encodings in some of our apps that are using Objective C++ and passing C++ types in Objective C methods, or have C++ types as instance variables. Templates are especially notorious for generating huge amounts of Objective C runtime information. I did a write up on it here:


but am looking for a better solution than my hacky "smart pointers". As a first step I wanted to have a warning I could control to understand where my problem spots are.

I would appreciate any thoughts on 


It is my first real foray into clang coding, so I expect my implementation is naïve.

Tracking bug:


Cheers,
Dave

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Warning for large Objective C runtime encodings (-Wobjc-encodings-larger-than=)

Richard Smith via cfe-dev

On 11.12.18 05:06, Dave MacLachlan via cfe-dev wrote:

> Hey esteemed colleagues,
>
> We recently noticed that we were generating some incredibly large
> Objective C runtime encodings in some of our apps that are using
> Objective C++ and passing C++ types in Objective C methods, or have
> C++ types as instance variables. Templates are especially notorious
> for generating huge amounts of Objective C runtime information. I did
> a write up on it here:
>
> https://medium.com/@dmaclach/objective-c-encoding-and-you-866624cc02de
>
> but am looking for a better solution than my hacky "smart pointers".
> As a first step I wanted to have a warning I could control to
> understand where my problem spots are.
>
> I would appreciate any thoughts on
>
> https://reviews.llvm.org/D55544
>
> It is my first real foray into clang coding, so I expect my
> implementation is naïve.
>
> Tracking bug:
>
> https://bugs.llvm.org/show_bug.cgi?id=38346
>
> Cheers,
> Dave
>

Hi

This is a an idea, that may or may not be useful, depending on your
circumstances.

What you could do is turn off the "bool EncodeBlockParameters, bool
EncodeClassNames, bool EncodePointerToObjCTypedef" (especially the
latter) flags passed to ASTContext::getObjCEncodingForTypeImpl,
depending on a newly introduced compiler flag in `Options.td`. The
resulting encodings are much smaller yet remain compatible. The amount
of code out there that actually correctly introspects C++ type @encodes
is probably extremely close to zero.

Usually the decision to use extended or traditional @encode is made at
the runtime level. My runtime
(https://github.com/mulle-objc/mulle-objc-runtime) uses extended format,
but I don't support C++ anyway :) I could see a warning or compiler
option like this as being useful, especially if the type is used in a
lot of methods. But then this could also be part of the runtime...

I also can't help but comment, that mixing C++ and Objective-C gets you
the worst of both worlds. :)

Ciao

    Nat!


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Warning for large Objective C runtime encodings (-Wobjc-encodings-larger-than=)

Richard Smith via cfe-dev
Thanks Nat!

I'll look into it once this hopefully gets checked in.

Cheers,
Dave

On Tue, Dec 11, 2018 at 12:44 PM Nat! via cfe-dev <[hidden email]> wrote:

On 11.12.18 05:06, Dave MacLachlan via cfe-dev wrote:
> Hey esteemed colleagues,
>
> We recently noticed that we were generating some incredibly large
> Objective C runtime encodings in some of our apps that are using
> Objective C++ and passing C++ types in Objective C methods, or have
> C++ types as instance variables. Templates are especially notorious
> for generating huge amounts of Objective C runtime information. I did
> a write up on it here:
>
> https://medium.com/@dmaclach/objective-c-encoding-and-you-866624cc02de
>
> but am looking for a better solution than my hacky "smart pointers".
> As a first step I wanted to have a warning I could control to
> understand where my problem spots are.
>
> I would appreciate any thoughts on
>
> https://reviews.llvm.org/D55544
>
> It is my first real foray into clang coding, so I expect my
> implementation is naïve.
>
> Tracking bug:
>
> https://bugs.llvm.org/show_bug.cgi?id=38346
>
> Cheers,
> Dave
>

Hi

This is a an idea, that may or may not be useful, depending on your
circumstances.

What you could do is turn off the "bool EncodeBlockParameters, bool
EncodeClassNames, bool EncodePointerToObjCTypedef" (especially the
latter) flags passed to ASTContext::getObjCEncodingForTypeImpl,
depending on a newly introduced compiler flag in `Options.td`. The
resulting encodings are much smaller yet remain compatible. The amount
of code out there that actually correctly introspects C++ type @encodes
is probably extremely close to zero.

Usually the decision to use extended or traditional @encode is made at
the runtime level. My runtime
(https://github.com/mulle-objc/mulle-objc-runtime) uses extended format,
but I don't support C++ anyway :) I could see a warning or compiler
option like this as being useful, especially if the type is used in a
lot of methods. But then this could also be part of the runtime...

I also can't help but comment, that mixing C++ and Objective-C gets you
the worst of both worlds. :)

Ciao

    Nat!


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev