> On Mar 6, 2017, at 10:17 AM, Lobron, David <[email protected]> wrote:
>
> Hi Akira,
>
> Pardon my slowness in addressing your question.
>
>> This patch changes the encoding of an id conforming to a protocol, which I
>> think was not intended: For example:
>>
>> @encode(id<NSObject>)
>>
>> Would passing IVD to the call to getObjCEncodingForType in
>> CGObjCGNU::GenerateClass solve the problem?
>
> Are you suggesting that passing IVD instead of just IVD->getType() will tell
> getObjCEncodingForType whether the code being compiled is a protocol, as
> opposed to an object? I'm a little confused here, because IVD is an object
> of type ObjCIvarDecl, which is supposed to represent an instance variable,
> not a protocol. Also, I don't see anything in the definition of ObjCIvarDecl
> (in AST/DeclObjC.h) that would tell us whether it represents an instance
> variable or a protocol. Can you explain the case you are concerned about a
> little more?
>
My concern is that the patch changes the encoding of @encode(id<NSObject>) on
Darwin, which I think isn’t what you are trying to fix. If you compile the
following code with command “clang -cc1 -triple x86_64-apple-macosx”, the type
encoding changes after applying the patch.
const char *foo() {
return @encode(id<NSObject>);
}
It seems like you can fix your problem without affecting Darwin by passing an
extra argument to getObjCEncodingForType, just like
CGObjCCommonMac::GetMethodVarType does.
> If IVD can in fact tell us whether the code being compiled is an object, then
> we can make the EncodeClassNames argument of getObjCEncodingForTypeImpl true
> for ivars and false for protocols.
>
> Thanks!
>
> --David
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
