[cfe-dev] [PATCH] add unconditional support for @encode block descriptor string

[David Chisnall]

On 20 Feb 2010, at 01:21, Fariborz Jahanian wrote:

>> 1) ? actually signifies 'unknown type', not 'function type'
> Granted you may not be looking at our Darwin source tree. But here it is:
> 
> else if (code == FUNCTION_TYPE) /* '?' */
>    obstack_1grow (&util_obstack, '?');

Perhaps someone should update the Apple documentation then:

http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtTypeEncodings.html

Unless the people who write documentation only have access to the GNU source code - your documentation corresponds with our implementation...

>> typedef void(^foo)(id, void*);   @encode(foo);
>> 
>> This currently returns "@?" if foo is any block type, rather than the type encoding that we are storing with the block.  To get the block type encoding, we need to look up the type of a template block at run time, which prevents some optimisations when you test that two type encodings match, because neither is known at compile time (even though one actually is).
> 
> Fact of the matter is that we cannot change block's encoding at this time.
> If you are using the same api to store encoding in block that @encode uses, you will get "@?". This is not very helpful. You need to write your
> own encoding logic for block's detailed encoding to store in block's descriptor.

The code to create the encoding stored with the block already exists.  I wrote it months ago.  Blaine has now modified where it is stored and made it unconditional.  

What is lacking, is some way for users of clang to get this type encoding at compile time, without having to construct it themselves (or poke the semi-private block structure).  The simplest way of supporting this would be for @encode on a block type to return the type of the block, rather than a generic type.  

If this would break existing code, then we should consider adding a new @encode-like mechanism that can be used to get compile-time type encodings for block types.  If we're doing that, then it would be nice for the same mechanism to support type encodings for functions and methods.

David

-- Sent from my PDP-11