Skip to content
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.

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

clang doesn't handle friend member functions correctly #9077

Closed
nico opened this issue Nov 30, 2010 · 2 comments
Closed

clang doesn't handle friend member functions correctly #9077

nico opened this issue Nov 30, 2010 · 2 comments
Labels
bugzilla Issues migrated from bugzilla c++

Comments

@nico
Copy link
Contributor

nico commented Nov 30, 2010

Bugzilla Link 8705
Resolution FIXED
Resolved on Feb 14, 2011 01:14
Version unspecified
OS All
CC @DougGregor,@zmodem,@rjmccall

Extended Description

gcc 4.2 accepts the following program:

class B {
public:
void b(int a);
void c(int a);
};

class A {
private:
static int a();
friend void B::c(int);
};

//void B::b(int a = A::a()) {} // Should error
void B::c(int a = A::a()) {}

clang rejects it with

test.cc:14:22: error: 'a' is a private member of 'A'
void B::c(int a = A::a()) {}
^
test.cc:9:14: note: declared private here
static int a();
^
1 error generated.

(Reverting r120299 does not make this go away.)

@zmodem
Copy link
Collaborator

zmodem commented Feb 2, 2011

Here is another example:

class A {
void a(int);
};

class B {
static int x;
friend void A::a(int);
friend void f(int);
};

void A::a(int foo = B::x) {} // This does not compile.
void f(int foo = B::x) {} // This compiles.

The reason the first function doesn't compile is that the access control check for the name in the default argument expression is performed before the declarator has been fully parsed.

This means that the EffectiveContext used by CheckAccess doesn't contain any functions. Since there are no functions, nothing is matched by the friend declaration.

For the non-member function f, it works because access control check gets delayed. There's a comment about this (SemaAccess.cpp:1263) that says "If we're currently parsing a top-level declaration, delay diagnostics." I'm not really sure why.

Is there a way to delay diagnostics for the member function declaration in this case? Or to get the DeclContext set sooner?

I'd be happy to try to come up with a patch if someone could point me in the right direction.

@rjmccall
Copy link
Contributor

Fixed in r125485.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++
Projects
None yet
Development

No branches or pull requests

3 participants