[Bug c++/19377] Using declaration in "private" part causes "protected" diagnostic

[harald at gigawatt dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #12 from Harald van Dijk <harald at gigawatt dot nl> ---
Fabien, are you sure that the test case in comment 9 is invalid? C++11 reads

"In a using-declaration used as a member-declaration, the nested-name-specifier
shall name a base class of the class being defined. If such a using-declaration
names a constructor, the nested-name-specifier shall name a direct base class
of the class being defined; otherwise it introduces the set of declarations
found by member name lookup (10.2, 3.4.3.1)."

which makes sense: any inherited member, even from an indirect base class, can
be introduced into the current class, except for an indirect base class's
constructor.

As for "It is invalid for a second reason, 'using Base::i' is declared
(implicitly) in a private section, so inaccessible in DerivedDerived.", the
DerivedDerived using declaration uses a fully qualified ns::Base::i, the
visibility of which should depend on the visibility in Base, not the visibility
in Derived. If the code used ns::Derived::i, then it would make sense to issue
an error, and clang does emit an error in that case.

As for being separate from this bug, a trivial change of that test case to

namespace ns {
  class Base {
  protected:
    int i;
  };
  class Derived : public Base {
    using Base::i;
  };
}
class DerivedDerived : public ns::Derived {
  using ns::Base::i;
};

makes GCC emit

test.cc:4:9: error: ‘int ns::Base::i’ is protected
     int i;
         ^
test.cc:11:7: error: within this context
 class DerivedDerived : public ns::Derived {
       ^

which is exactly the error message that this bug is about. Similarly, changing
the "protected:" to "public:" in the original test case changes the error
message from "protected" to "inaccessible".