[cfe-dev] [RFC] Warning for large Objective C runtime encodings (-Wobjc-encodings-larger-than=)
Nat! via cfe-dev
cfe-dev at lists.llvm.org
Tue Dec 11 12:44:42 PST 2018
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:
> 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:
This is a an idea, that may or may not be useful, depending on your
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. :)
More information about the cfe-dev