[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