LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 37424 - Invalid private check for member addresses
Summary: Invalid private check for member addresses
Status: NEW
Alias: None
Product: clang
Classification: Unclassified
Component: C++ (show other bugs)
Version: trunk
Hardware: PC All
: P normal
Assignee: Unassigned Clang Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-11 13:00 PDT by Anton Korobeynikov
Modified: 2020-04-17 14:50 PDT (History)
4 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Korobeynikov 2018-05-11 13:00:14 PDT 
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.
Comment 1 Richard Smith 2018-05-11 13:12:05 PDT 
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.
Comment 2 Sergej Jaskiewicz 2020-04-17 14:50:47 PDT 
Addressed in https://reviews.llvm.org/D78404.