> On Feb 18, 2015, at 7:45 PM, Richard Smith <[email protected]> wrote: > > On Wed, Feb 18, 2015 at 5:20 PM, Ben Langmuir <[email protected] > <mailto:[email protected]>> wrote: > >> On Feb 18, 2015, at 5:09 PM, Richard Smith <[email protected] >> <mailto:[email protected]>> 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 >> <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.
Okay, makes sense. I should also add a test case like that. > > Thanks for the review, > > Ben > >> >> On Mon, Jan 26, 2015 at 9:08 AM, Ben Langmuir <[email protected] >> <mailto:[email protected]>> wrote: >> This patch diagnoses a missing ‘typename’ keyword on nested template types >> like A<T>::B<U>, to fix llvm.org/pr16909 <http://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 >> >> >> >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
