[patch] Correctly classifying PackExpansionType as NON_CANONICAL_UNLESS_DEPENDENT

David Blaikie dblaikie at gmail.com
Sat Jul 13 14:12:26 PDT 2013


On Fri, Jul 12, 2013 at 5:41 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> LGTM
>
> Please commit the getTypeInfoImpl refactoring separately

(and the "..." there should actually have a message, "should not see
> dependent types here" or something).


Comment added & committed as r186260.


>
> Also, please ensure we have some lit test coverage for non-dependent pack
> expansion types; something like:
>
> template<typename T> using X = int;
> template<typename ...T> void f(X<T> ...xs);
> void g() { f<void,void,void>(1, 2, 3); }
>
> ... should do the trick.
>

Added to test/CXX/temp/temp.decls/temp.alias/p3.cpp and committed as r186261

Then committed the debug info improvement (including the ASTConsumer
extension for 'required complete type') that we discussed previously on top
of this in r186262.


>
>
> On Fri, Jul 12, 2013 at 4:47 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> Richard - just checking if you have any thoughts about this before commit.
>>
>> I'd really like to have a test case for it, but the follow-on patch will
>> fail provide test coverage for this at worst.
>>
>>
>> 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)
>>>
>>> Thanks,
>>> - David
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130713/b5c30c79/attachment.html>


More information about the cfe-commits mailing list