Patch for Bug 30413, including test case

[Akira Hatanaka via cfe-commits]

> On Mar 6, 2017, at 10:17 AM, Lobron, David <dlobron at akamai.com> 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