[Bug c++/96204] New: gcc complains about private member access in SFINAE context

[Bug c++/96204] New: gcc complains about private member access in SFINAE context

[lts-rudolph at gmx dot de]

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

            Bug ID: 96204
           Summary: gcc complains about private member access in SFINAE
                    context
           Product: gcc
           Version: 10.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lts-rudolph at gmx dot de
  Target Milestone: ---

gcc complains with following error in the example code:

main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
   59 | struct has_set_attr_method<T,
void_t<decltype(std::declval<T>().setAttr(1))>> {
      |                                              
~~~~~~~~~~~~~~~~~~~~~~~~~^~~
main.cpp:85:14: note: declared private here
   85 |         void setAttr(int x) {
      |              ^~~~~~~
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
   59 | struct has_set_attr_method<T,
void_t<decltype(std::declval<T>().setAttr(1))>> {
      |                                              
~~~~~~~~~~~~~~~~~~~~~~~~~^~~
main.cpp:85:14: note: declared private here
   85 |         void setAttr(int x) {
      |              ^~~~~~~
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
   59 | struct has_set_attr_method<T,
void_t<decltype(std::declval<T>().setAttr(1))>> {
      |                                              
~~~~~~~~~~~~~~~~~~~~~~~~~^~~
main.cpp:85:14: note: declared private here
   85 |         void setAttr(int x) {


Full code example:

---------------
template <typename, typename = void_t<>>
struct has_set_attr_method {
    static constexpr bool value = false;
};
template <typename T>
struct has_set_attr_method<T, void_t<decltype(std::declval<T>().setAttr(1))>> {
    static constexpr bool value = true;
};

struct Parent
{
    public:
        template<typename T>
            static void create()    {   
                auto obj = T::create();
                if constexpr(has_set_attr_method<T>::value) {
                    cout << "has setAttr" << endl;
                } else {
                    cout << "no setAttr" << endl;
                }
            }
};

struct Child : public Parent {
    public:
        friend class Parent;
        static auto create() {
            return Child();
        }

    private:
        void setAttr(int x) {
        }
};

int main(int argc, char const *argv[]) {
    Parent::create<Child>();
    return 0;
}

---------------

Interestingly the failure depends on "friend" declaration inside "Child".

[Bug c++/96204] gcc complains about private member access in SFINAE context

[lts-rudolph at gmx dot de]

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

--- Comment #1 from Klaus Rudolph <lts-rudolph at gmx dot de> ---
Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335

[Bug c++/96204] gcc complains about private member access in SFINAE context

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-15
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |rejects-valid

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Klaus Rudolph from comment #0)
> Full code example:

The example is incomplete, and you didn't say how you're compiling it.

This is the complete example, and requires -std=c++17

#include <type_traits>
#include <iostream>
using std::void_t;
using std::cout;
using std::endl;

template <typename, typename = void_t<>>
struct has_set_attr_method {
    static constexpr bool value = false;
};
template <typename T>
struct has_set_attr_method<T, void_t<decltype(std::declval<T>().setAttr(1))>> {
    static constexpr bool value = true;
};

struct Parent
{
    public:
        template<typename T>
            static void create()    {   
                auto obj = T::create();
                if constexpr(has_set_attr_method<T>::value) {
                    cout << "has setAttr" << endl;
                } else {
                    cout << "no setAttr" << endl;
                }
            }
};

struct Child : public Parent {
    public:
        friend class Parent;
        static auto create() {
            return Child();
        }

    private:
        void setAttr(int) {
        }
};

int main() {
    Parent::create<Child>();
}



#include <type_traits>
#include <iostream>
using std::void_t;
using std::cout;
using std::endl;


(In reply to Klaus Rudolph from comment #1)
> Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335

I don't think so, that is "accepts-invalid" not "rejects-valid" and it was
fixed years ago.

[Bug c++/96204] gcc complains about private member access in SFINAE context

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reduced:

template<typename...> using void_t = void;

template<typename T> T&& declval();

template <typename, typename = void>
struct has_set_attr_method {
    static constexpr bool value = false;
};
template <typename T>
struct has_set_attr_method<T, void_t<decltype(declval<T>().setAttr(1))>> {
    static constexpr bool value = true;
};

struct Parent
{
    public:
        template<typename T>
            static bool create()    {   
                return has_set_attr_method<T>::value;
            }
};

struct Child : public Parent {
    public:
        friend class Parent;
    private:
        void setAttr(int) {
        }
};

int main() {
    Parent::create<Child>();
}

[Bug c++/96204] gcc complains about private member access in SFINAE context

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The reduced example above doesn't need -std=c++17, it should compile in C++11
or later.

[Bug c++/96204] gcc complains about private member access in SFINAE context

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |ppalka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org

[Bug c++/96204] gcc complains about private member access in SFINAE context

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:9f26e34a5a9614a5b66f146752ecef9ea67b3e2d

commit r12-1829-g9f26e34a5a9614a5b66f146752ecef9ea67b3e2d
Author: Patrick Palka <ppalka@redhat.com>
Date:   Sat Jun 26 11:05:54 2021 -0400

    c++: access scope during partial spec matching [PR96204]

    Here, when determining whether the partial specialization matches
    has_type_member<Child>, we do so from the scope of where the template-id
    appears rather than from the scope of the specialization, and this
    causes us to select the partial specialization (since Child::type is
    accessible from Parent).  When we later instantiate this partial
    specialization, we've entered the scope of the specialization and so
    substitution into e.g. the DECL_CONTEXT of has_type_member::value fails
    with access errors since the friend declaration that we relied on to
    choose the partial specialization no longer applies.

    It seems the appropriate access scope from which to perform partial
    specialization matching is the specialization itself (similar to how
    we check access of base-clauses), which is what this patch implements.

            PR c++/96204

    gcc/cp/ChangeLog:

            * pt.c (instantiate_class_template_1): Enter the scope of the
            type when calling most_specialized_partial_spec.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/access40.C: New test.
            * g++.dg/template/access40a.C: New test.

[Bug c++/96204] gcc complains about private member access in SFINAE context

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |12.0

--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 12.

[Bug c++/96204] gcc complains about private member access in SFINAE context

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:613497aa6e28ca009d8498002424019d2a8a9ca5

commit r12-1945-g613497aa6e28ca009d8498002424019d2a8a9ca5
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Jun 30 20:21:16 2021 -0400

    c++: Extend the PR96204 fix to variable templates too

    r12-1829 corrected the access scope during partial specialization
    matching of class templates, but overlooked the variable template case.
    This patch moves the access scope adjustment to within
    most_specialized_partial_spec so that all callers can benefit.

    This patch also adjusts a couple of these callers to avoid always
    passing the most general template of a variable template specialization,
    since that'd cause us to push the wrong access scope for e.g. the second
    testcase below (we'd push A<T> instead of A<int>/A<char>).  We ought to
    be passing the partially instantiated template instead.

            PR c++/96204

    gcc/cp/ChangeLog:

            * pt.c (finish_template_variable): Pass the partially
            instantiated template and its args to instantiate_template.
            (instantiate_class_template_1): No need to call
            push_nested_class and pop_nested_class around the call to
            most_specialized_partial_spec.
            (instantiate_template_1): Pass the partially instantiated
            template to lookup_template_variable.
            (most_specialized_partial_spec):  Use push_access_scope_guard
            to set the access scope appropriately.  Use
            deferring_access_check_sentinel to force access to get checked
            immediately.
            (instantiate_decl): Just pass the VAR_DECL to
            most_specialized_partial_spec.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/access41.C: New test.
            * g++.dg/template/access41a.C: New test.

[Bug c++/96204] gcc complains about private member access in SFINAE context

[Martin.Jansa at gmail dot com]

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

Martin Jansa <Martin.Jansa at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Martin.Jansa at gmail dot com

--- Comment #8 from Martin Jansa <Martin.Jansa at gmail dot com> ---
Can this be please backported to 11 release as well?

[Bug c++/96204] gcc complains about private member access in SFINAE context

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eieio at google dot com

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 82478 has been marked as a duplicate of this bug. ***