Skip to content

Invalid private check for member addresses #36772

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
asl opened this issue May 11, 2018 · 4 comments
Closed

Invalid private check for member addresses #36772

asl opened this issue May 11, 2018 · 4 comments
Labels
bugzilla Issues migrated from bugzilla c++ clang:frontend Language frontend issues, e.g. anything involving "Sema"

Comments

@asl
Copy link
Collaborator

asl commented May 11, 2018 •
edited by Endilll
Loading

Bugzilla Link 37424
Version trunk
OS All
CC @DougGregor,@broadwaylamb,@zygoloid

Extended Description

Consider the following code:

class TestClass {
private:
    void func();
    void func2();
    void func2(int);
};
template <void (TestClass::*)()> class TemplateClass { };
template class TemplateClass<&TestClass::func>;
template class TemplateClass<&TestClass::func2>;

clang rejects the second instantiation while gcc does not. If I'm reading the standard correctly we should accept both.
@zygoloid
Copy link
Mannequin

zygoloid mannequin commented May 11, 2018 •
edited by Endilll
Loading

Confirmed, we're probably leaving the "no access checking errors" context before checking and converting the arguments rather than afterwards.

We also seem to get this wrong for both the overloaded and non-overload case for a partial specialization, for which the same rules apply ([temp.class.spec]p10):

template<typename T, void (TestClass::*)()> class TemplateClass2 {};
template<typename T> class TemplateClass2<T, &TestClass::func>;
template<typename T> class TemplateClass2<T, &TestClass::func2>;

... but it looks like we don't implement the rule at all for partial specializations.

@broadwaylamb
Copy link
Contributor

Addressed in https://reviews.llvm.org/D78404.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@Endilll Endilll added the clang:to-be-triaged Should not be used for new issues label Jul 20, 2024
@Endilll Endilll added clang:frontend Language frontend issues, e.g. anything involving "Sema" and removed clang:to-be-triaged Should not be used for new issues labels Mar 10, 2025
@llvmbot
Copy link
Member

llvmbot commented Mar 10, 2025

@llvm/issue-subscribers-clang-frontend

Author: Anton Korobeynikov (asl)

| | | | --- | --- | | Bugzilla Link | [37424](https://llvm.org/bz37424) | | Version | trunk | | OS | All | | CC | @DougGregor,@broadwaylamb,@zygoloid |

Extended Description

Consider the following code:

class TestClass {
private:
    void func();
    void func2();
    void func2(int);
};
template &lt;void (TestClass::*)()&gt; class TemplateClass { };
template class TemplateClass&lt;&amp;TestClass::func&gt;;
template class TemplateClass&lt;&amp;TestClass::func2&gt;;

clang rejects the second instantiation while gcc does not. If I'm reading the standard correctly we should accept both.

@shafik
Copy link
Collaborator

shafik commented Mar 13, 2025

clang accepts both now: https://godbolt.org/z/KPEvoWd3o

@shafik shafik closed this as completed Mar 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla c++ clang:frontend Language frontend issues, e.g. anything involving "Sema"
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@asl @shafik @Endilll @broadwaylamb @llvmbot