[PATCH] PR16909: Diagnose missing 'typename' on dependent template

Richard Smith richard at metafoo.co.uk
Wed Feb 18 19:45:22 PST 2015


On Wed, Feb 18, 2015 at 5:20 PM, Ben Langmuir <blangmuir at apple.com> wrote:

>
> On Feb 18, 2015, at 5:09 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> Makes sense to me. I'm not too unhappy about the class.qual p2 case; it's
> not ideal, but the new diagnostic explains one way to fix the problem,
> which is in some sense an improvement, and it only arises if the user makes
> several errors all at once. A FIXME in the test would be nice, though.
>
>
> Okay.
>
>
> Should we also diagnose the missing 'template' keyword? (I'd note that
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1710 removes
> the need for that keyword here, but isn't fully baked yet).
>
>
> Yeah it’s probably better to not have the user recompile just to get the
> second error.
>
>
> More generally, should we rebuild the whole nested name specifier as a
> dependent specifier, rather than just the last component?
>
>
> My goal was to match what was produced if you put in the typename and
> template keywords.  I’m willing to admit I might have got it wrong - it’s
> been a while since I traced through it.  I’ll take a look.
>

I agree that's what we should be doing. My concern is what happens if you
have:

  template<typename T> X<T>::Y<T>::Z<T> f();

It looks like you'll only rebuild the X<T>::Y<T>::Z to be a dependent
template name, and the X<T>::Y will be treated as a non-dependent name as a
member of the primary X<T> template.


> Thanks for the review,
>
> Ben
>
>
> On Mon, Jan 26, 2015 at 9:08 AM, Ben Langmuir <blangmuir at apple.com> wrote:
>
>> This patch diagnoses a missing ‘typename’ keyword on nested template
>> types like A<T>::B<U>, to fix llvm.org/pr16909. In addition to fixing an
>> accepts-invalid, in C++11 such types would cause assertion failures and/or
>> invalid LLVM IR when used with ‘auto’.
>>
>> I’m not 100% sure if the changes to
>> test/CXX/basic/basic.lookup/basic.lookup.qual/class.qual/p2.cpp are
>> desirable, or if we should suppress the missing ‘typename’ diagnostic when
>> we’re already recovering on X<T>::X<T>.  I’m open to suggestions :-)
>>
>> Ben
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150218/503e7b90/attachment.html>


More information about the cfe-commits mailing list