On Mar 20, 2018, Jason Merrill <ja...@redhat.com> wrote:
> On Tue, Mar 20, 2018 at 6:07 PM, Alexandre Oliva <aol...@redhat.com> wrote:
>> On Mar 20, 2018, Jason Merrill <ja...@redhat.com> wrote:
>>> 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?
>> 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" }
>> };
> No, we look inside when we're trying to parse the qualified-id as the
> name of a declaration
Yeah, but that's not the case at hand. I guess we're miscommunicating.
I understood you were saying it was ok to peek in this case. Would you
please state, for clarity, what your stance is on peeking in this case,
specifically, in the B<T>::A::I::I within the definition of C above?
> in a declarator-id we can look into uninstantiated classes, otherwise
> there would be no way to define members of class templates.
> void X<T>::N::f() { } // looks inside X<T>
Of course, but then, we wouldn't get to a template-independent member.
A member of a template-dependent name is still template-dependent. It's
only when a qualified name maps to an external name that it might become
template-independent, and when this happens, I believe the qualified-id
is not one that can be used to define a member. Specifically:
struct K { struct L { static double j; }; };
template <typename T> struct M { struct N { static int i; }; };
template <typename T> struct O { typedef M<T> P; typedef K Q; };
template <typename T> int O<T>::P::N::i = 42;
template <typename T> double O<T>::Q::L::j = 42.0;
if we remap O<T>::P to M<T> and O<T>::Q to K, how will we realize the
given type-ids are not appropriate? Where will the template parmlist
belong when the qualified-id is taken as equivalent to K::L::j?
FWIW, we silently swallow the definition of i above (I think we
shouldn't), and we fail the same assert in resolve_typename_type when
parsing the definition of j.
So, you see, we do have problems with declarators, and we have problems
with types. AFAICT, we shouldn't simplify qualified-ids in declarators,
otherwise we'd fail to issue errors for the definitions above, and we
shouldn't simplify qualified-ids in types involving templates other than
the one we'd in.
So it's not clear to me what purpose the resolver is supposed to serve,
considering that simplifying the types seem to almost never be wanted.
But one issue is whether we can peek into dependent types, another is
whether we can and should simplify them. The answers to these questions
don't seem to be very clear to me. What is clear to me is that
refraining from simplifying from dependent to non-dependent enables us
to report errors that we were missing in both declarators and types, and
that simplifying from dependent to unrelated dependent prevents us from
reporting the error we should in the definition of i above. But is
there any case in which *not* simplifying causes problems?
>>> 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.
> Yes, as the comment says, a TYPENAME_TYPE should always have a
> dependent scope. In this case, the dependent scope was "typename
> B<T>::A", but just above we resolved it to just A, making it no longer
> dependent.
Then you got me thoroughly confused: what did you mean by 'the assert
should allow' a case that's a given?
--
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
