[Bug c++/99160] New: A wrong accessible check when using a using-declaration that introduces the names of type and function

[Bug c++/99160] New: A wrong accessible check when using a using-declaration that introduces the names of type and function

[xmh970252187 at gmail dot com]

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

            Bug ID: 99160
           Summary: A wrong accessible check when using a
                    using-declaration that introduces the names of type
                    and function
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xmh970252187 at gmail dot com
  Target Milestone: ---

````cpp
#include <iostream>
struct A{
    struct C{
        using type = int;
    };
    void C(){}  //#1 if comment out this function definition, GCC will compile 
                //   this  example  
};
struct B:private A{
    using A::C;
};
int main(){
    B::C::type c;  //#2
}
````
For this example, GCC will report an error, which says "'struct A::C' is
inaccessible within this context". The result of this example is
https://godbolt.org/z/ddfrPM. If we comment out `void C(){}`, GCC will compile
the example.  

According to [namespace.udecl]#19. 
> A synonym created by a using-declaration has the usual accessibility for a member-declaration.   

That means the name `C` is accessible in the  nested-name-specifier at #2(the
name would be found in the scope of `B` in which the using-declaration will
create the synonym name for that name, the created name has the same
accessibility as the member-declaration)

Clang can compile this example even if we do not comment out the function
definition at #1

[Bug c++/99160] A wrong accessible check when using a using-declaration that introduces the names of type and function

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-08-12
      Known to fail|                            |4.1.2
             Blocks|                            |12944
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.
Though MSVC agrees with GCC:
<source>(14): error C2247: 'A::C::type' not accessible because 'B' uses
'private' to inherit from 'A'


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug c++/99160] A wrong accessible check when using a using-declaration that introduces the names of type and function

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think GCC is correct here. The using-declaration finds a class and a
function, and ignores the class, which means it only redeclares the function as
public. That means B::C is indeed referring to a private name.

[Bug c++/99160] A wrong accessible check when using a using-declaration that introduces the names of type and function

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #2)
> he using-declaration finds a class and a function, and ignores the class,

See [namepace.udecl] p1 and [basic.lookup.general] p4.

[Bug c++/99160] A wrong accessible check when using a using-declaration that introduces the names of type and function

[xmh970252187 at gmail dot com]

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

--- Comment #4 from jim x <xmh970252187 at gmail dot com> ---
[namespace.udecl#1] says
> Each using-declarator in a using-declaration names the set of declarations found by lookup ([basic.lookup.qual]) for the using-declarator, except that class and enumeration declarations that would be discarded are merely ignored when checking for ambiguity ([basic.lookup]), conversion function templates with a dependent return type are ignored, and certain functions are hidden as described below. 

That means, in the eventual lookup set, the class and enumeration are also
included(if any). 


[basic.lookup.qual#general-1] says
> Lookup of an identifier followed by a ​::​ scope resolution operator considers only namespaces, types, and templates whose specializations are types. 

This means the lookup for `C` in `B::C::type` only consideres types in this
case.

[namespace.udecl#16] says

> A using-declaration has the usual accessibility for a member-declaration. Base-class constructors considered because of a using-declarator are accessible if they would be accessible when used to construct an object of the base class; the accessibility of the using-declaration is ignored.

Hence, the name introduced by the using-declaration will have the same
accessibility as it.

[Bug c++/99160] A wrong accessible check when using a using-declaration that introduces the names of type and function

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
If that's what "ignored" means here then I think a note would be helpful.

[Bug c++/99160] A wrong accessible check when using a using-declaration that introduces the names of type and function

[xmh970252187 at gmail dot com]

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

--- Comment #6 from jim x <xmh970252187 at gmail dot com> ---
struct A{
    struct Name{};
    void Name(){}
};
struct B:A{
    using A::Name;  //#1
};
int main() {
   struct B::Name d;
}

According to [basic.lookup#general-4], the lookup set occurs at `#1` would
discard the declaration of class "Name" since there is another declaration be
found. [namespace.udecl#1] just requires these type declarations are ignored
when checking for ambiguity but are not actually ignored in the the set of
declarations.