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

Fariborz Jahanian fjahanian at apple.com
Fri Dec 19 12:09:31 PST 2008


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)...
   //

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. :).

- Fariborz




More information about the cfe-dev mailing list