On Mar 20, 2018, Jason Merrill <ja...@redhat.com> wrote:
> On Fri, Mar 16, 2018 at 5:38 PM, Alexandre Oliva <aol...@redhat.com> wrote:
>> resolve_typename_type may peek into template types that might still be
>> specialized. In some cases, e.g. g++.dg/template/friend48.C or
>> g++.dg/template/decl2.C, that is exactly the right thing to do. In
>> others, like the newly-added testcase g++.dg/template/pr84789.C, it
>> isn't, and if the qualifying scope happens to resolve to a non-template
>> type, we resolve to that and then fail the assert that checks we still
>> have a template-dependent scope.
> We're looking inside them because we're trying to parse a declarator;
> the tentative parse will fail in this case, because we aren't in a
> declarator, but that doesn't mean it's wrong to peek.
Huh? We're referencing members of an unrelated template that AFAIK
needs not even be defined at that point, and even if it is, it could
still be specialized afterwards. How can it possibly be right to
short-circuit such nested names? How would template
instantiation/specialization get a chance to do the proper mapping?
template<typename> struct B : A {}; // would /*: A {}*/ make any diff?
template<typename T> struct C : B<T> // would /* : B<T>*/ make any diff?
{
B<T>::A::I::I i; // { dg-error "typename" }
};
Is it by any chance the fact that B<T> is a base class for C<T> that
makes it correct to peek into it? I don't recall any exception of this
sort.
> I disagree; it seems to me that the assert should allow the case where
> the scope was originally dependent, but got resolved earlier in the
> function.
Doesn't the function always take dependent scopes? I for some reason
thought that was the case.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
