[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