[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Jonathan Wakely changed: What|Removed |Added CC||eieio at google dot com --- Comment #9 from Jonathan Wakely --- *** Bug 82478 has been marked as a duplicate of this bug. ***
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Martin Jansa changed: What|Removed |Added CC||Martin.Jansa at gmail dot com --- Comment #8 from Martin Jansa --- Can this be please backported to 11 release as well?
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:613497aa6e28ca009d8498002424019d2a8a9ca5 commit r12-1945-g613497aa6e28ca009d8498002424019d2a8a9ca5 Author: Patrick Palka 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 instead of A/A). 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #6 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9f26e34a5a9614a5b66f146752ecef9ea67b3e2d commit r12-1829-g9f26e34a5a9614a5b66f146752ecef9ea67b3e2d Author: Patrick Palka 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, 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 Patrick Palka 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #4 from Jonathan Wakely --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #3 from Jonathan Wakely ---
Reduced:
template using void_t = void;
template T&& declval();
template
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
static constexpr bool value = true;
};
struct Parent
{
public:
template
static bool create(){
return has_set_attr_method::value;
}
};
struct Child : public Parent {
public:
friend class Parent;
private:
void setAttr(int) {
}
};
int main() {
Parent::create();
}
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-15
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
--- Comment #2 from Jonathan Wakely ---
(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
#include
using std::void_t;
using std::cout;
using std::endl;
template >
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
static constexpr bool value = true;
};
struct Parent
{
public:
template
static void create(){
auto obj = T::create();
if constexpr(has_set_attr_method::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();
}
#include
#include
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #1 from Klaus Rudolph --- Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
