[cfe-dev] Smart pointer usage in the Parser/Actions

steve naroff snaroff at apple.com
Fri Dec 19 12:39:42 PST 2008


On Dec 19, 2008, at 3:09 PM, Fariborz Jahanian wrote:

>
> Ran into this issue when looking at encoding of methods:
>
> @interface Test
> -(id) test3: (Test  [3][4])b;
> @end
>
> @implementation Test
> -(id) test3: (Test [3][4])b {  }
> @end
>
>
> We do type-decay on arrays too early. So, encoding of the method  
> type is not
> same as gcc's. I also saw this note  in clang:
>
> // Perform the default function/array conversion (C99 6.7.5.3p[7,8]).
>  // Doing the promotion here has a win and a loss. The win is the  
> type for
>  // both Decl's and DeclRefExpr's will match (a convenient invariant  
> for the
>  // code generator). The loss is the orginal type isn't preserved.  
> For example:
>  //
>  // void func(int parmvardecl[5]) { // convert "int [5]" to "int *"
>  //    int blockvardecl[5];
>  //    sizeof(parmvardecl);  // size == 4
>  //    sizeof(blockvardecl); // size == 20
>  // }
>  //
>  // For expressions, all implicit conversions are captured using the
>  // ImplicitCastExpr AST node (we have no such mechanism for Decl's).
>  //
>  // FIXME: If a source translation tool needs to see the original  
> type, then
>  // we need to consider storing both types (in ParmVarDecl)...
>  //
>

Yep, that's my comment/FIXME.

> Should we do what FIXME suggests (for objc method params only).  Or  
> should we
> do type-decay lazily.  latter saves us a slot at the expense of more  
> wide-spread change.
> My preference is for the FIXME approach. But I know how sensitive we  
> are to adding a
> slot to AST node. :).
>

Ah yes, GCC's wasteful tree nodes caused me extreme trauma as a young  
lad:-)

As you say, my preference is for the lazy approach. When I wrote this  
code, I was clearly too "lazy" to do it. Without some research, it's  
hard for me to estimate the difficulty. Since I didn't really need to  
original type, I simply added the FIXME.

A variation on the FIXME is to have a subclass of ParmVarDecl (e.g.  
ObjCParmVarDecl) that contains the original type (to support method  
encoding). This is still wasteful, however the waste is isolated to  
ObjC. Note that C++ is already wasting space (with the DefaultArg  
slot). Conceptually, I like the idea of having ObjC and C++ subclasses  
of ParmVarDecl.

What do you think?

snaroff

>
> - Fariborz
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20081219/f278dd32/attachment.html>


More information about the cfe-dev mailing list