This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [C++] comptypes and TYPENAME_TYPE
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Giovanni Bajo <giovannibajo at libero dot it>
- Cc: gcc at gcc dot gnu dot org
- Date: 15 Jun 2003 10:44:16 -0700
- Subject: Re: [C++] comptypes and TYPENAME_TYPE
- References: <22ff01c3335e$ca0ae580$e14e2697@bagio>
On Sun, 2003-06-15 at 09:54, Giovanni Bajo wrote:
> Hello,
>
> currently, comptypes handle TYPENAME_TYPES this way:
>
> + /* TYPENAME_TYPEs should be resolved if the qualifying scope is the
> + current instantiation. */
> + if (TREE_CODE (t1) == TYPENAME_TYPE)
> + t1 = resolve_typename_type_in_current_instantiation (t1);
> + if (TREE_CODE (t2) == TYPENAME_TYPE)
> + t2 = resolve_typename_type_in_current_instantiation (t2);
>
> (patch by Mark, here:
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02453.html)
>
> I was tracking c++/11105, this is the testcase:
>
> ----------------------------------------------
> template <typename T> struct S {
> struct I{};
> operator I* ();
> };
>
> template <typename T> struct S2 : S<T> {
> operator typename S<T>::I* ();
> };
>
> template struct S2<int>;
> ----------------------------------------------
>
> I noticed that, in mangle_conv_op_name_for_type we end up comparing
> "typename S<T>::I*" with "S<T>::I*". The comparison fails because S<T> (the
> scope of S<T>::I) is not the current open class (which happens to be S2<T>).
>
> Why is comptypes using resolve_typename_type_in_current_instantiation?
> Changing it to resolve_typename_type(t1, false) makes the testcase work, but
> it breaks mangle10.C and mangle12.C. Suggestions? Maybe I should add a new
> flag to comptypes like COMPARE_THROUGH_ALL_TYPENAMES and use it within
> mangle_conv_op_name_for_type?
The code in comptypes reflects the C++ committee's forthcoming revision
of the dependency rules. This stuff is not well-specified in the
standard, and does not behave the way people expect. The revisions will
attempt to resolve some of that confusion (although they way in which
they do that is not the way which I would choose.) Anyhow, the mangling
of the operator name should include the typename type -- as a typename
type.
I will look at the test case, but my guess is that it may make sense to
remove the use of same_type_p in mangle_conv_op_name_for_type, and the
error message that goes with it.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com