On Wed, Jun 12, 2013 at 9:15 AM, Reid Kleckner <[email protected]> wrote:
> On Tue, Jun 11, 2013 at 6:24 PM, Eli Friedman <[email protected]>wrote: > >> On Tue, Jun 11, 2013 at 3:09 PM, Reid Kleckner <[email protected]> wrote: >> >>> For a Type held by an AST node, I completely agree, and I'll try to >>> address that. For a type held by a TypeSourceInfo, I disagree, the >>> FunctionProtoType should really hold the undecayed parameter types. >>> >> >> Hmm... I was thinking more along the lines of keeping around the >> un-decayed type, but automatically decaying it for the user of the API >> unless they explicitly request the un-decayed version. I'm not sure I like >> keeping different versions of the type in the AST nodes vs. TypeSourceInfo. >> > > Maybe, but it seems pretty heavyweight to add a custom iterator to do the > decay. Right now the iterator is just an ArrayRef. Every dynamic decay > will trigger a uniquing in the ASTContext, unless we put some kind of cache > into ArrayType or FunctionType similar to how CanonicalType works. > I think I'm going to abandon this change. I think I see a way forward on my real problem, which is mangling MS function types. I didn't realize that the TypeLoc holds the original ParmVarDecls. The ParmVarDecl holds both the decayed and undecayed type.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
