[patch] Correctly classifying PackExpansionType as NON_CANONICAL_UNLESS_DEPENDENT

David Blaikie dblaikie at gmail.com
Thu Jul 4 17:23:15 PDT 2013


On Fri, Jun 28, 2013 at 2:41 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Fri, Jun 21, 2013 at 1:45 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> Hi Richard,
>>
>> From our conversation/your help this morning, here's a patch that at
>> least solves my original problem (Type::getAs<TagDecl> on a RecordDecl
>> of a non-dependent alias template).
>>
>> Does this look about right? This doesn't address the further
>> simplification of getTypeInfoImpl that we were discussing, but I
>> expect that can be handled before/after (happy to do it, though, if
>> you would like me to have a go at it). Are there some test cases I
>> should add? (I don't know the code well enough to know if this
>> manifests in any real way, I assume it does though)
>>
> Untested, but I think this would have an effect on a testcase like the
> following:
>
> void g(...);
>
> template<int... numbers> void f(int ...x[numbers]) { g(**x...); }

Not sure what I should be looking for here, but at least superficially
my change doesn't seem to have affected this test case (no change in
diagnostics, no change in the dumped AST, so far as I can tell).

The specific sort of case this came up in was with non-dependent alias
templates such as: template<typename U> using T = int;
If that's any hint as to where this might crop up. We wouldn't treat
"T" as sugar & see through it to the int. (personally this came up
while I was trying to implement something else & calling "getAs" on a
clang::Type only to have it fail an assertion because the type was
both not sugared but not canonical)



More information about the cfe-commits mailing list