[Bug c++/114694] New: dependent-name alias type accepted in elaborated type specifier within a template

[Bug c++/114694] New: dependent-name alias type accepted in elaborated type specifier within a template

[ing.russomauro at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694

            Bug ID: 114694
           Summary: dependent-name alias type accepted in elaborated type
                    specifier within a template
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ing.russomauro at gmail dot com
  Target Milestone: ---

Here below you may find an example with a class named D, defining a nested
alias type which, in turn, is referred by an elaborated type specifier within a
function template f() instantiated with template type parameter equal to D.
The same with a class E where 'using' syntax is used.
In both cases, the alias-id is accepted.
The non-dependent alias-id ('Alias') is correctly refused.

The standard reads "If a typedef-name is used to identify the subject of an
elaborated-type-specifier ..., the program is ill-formed."

I see old tickets about elaborated-type-specifiers, as 11036, and 87781, and a
single open ticket 55809, but none of them seem related to the context of a
dependent-name alias within a template.


class C{public: void f(){};};

using Alias = C;

struct D
{
    typedef C Alias2;
};

struct E
{
    using Alias2 = C;
};

template<class T>
void f()
{
    //struct Alias x; -> error, as 'Alias' is an alias type
    struct T::Alias2 y; // WEIRDLY, no error here, despite 'Alias2' is
                         // an alias type when instantiated with either T=D or
T=E.
    y.f(); // avoids warning for unused variable
    typename T::Alias2 z; // ok no error with typename
    z.f(); // avoids warning for unused variable
}

void foo()
{
    //struct Alias a; -> error, as 'Alias' is an alias type
    //struct D::Alias2 a2; -> error, as 'D::Alias2' is an alias type

    f<D>();
    f<E>();
}

int main(){
    foo();
}

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There might be a dup somewhere ...

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> There might be a dup somewhere ...

PR 93816 is definitely related but it is not a dup since that has no dependent
types but it does have templates being involved.

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=21498

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
PR 21498 is another one in this area.

[Bug c++/114694] dependent-name alias type accepted in elaborated type specifier within a template

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114694

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-04-11
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.