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

Visibility attribute ignored on a type that's used in a function prototype earlier #12373

Closed
nico opened this issue Feb 14, 2012 · 6 comments
Closed
Labels
bugzilla Issues migrated from bugzilla c++

Comments

@nico
Copy link
Contributor

nico commented Feb 14, 2012

Bugzilla Link 12001
Resolution FIXED
Resolved on Feb 22, 2012 22:25
Version unspecified
OS All
CC @DougGregor

Extended Description

$ cat repro-weak-private-external.ii

template
struct BindState;

template
struct BindState<void(P1)> {
};

template
void Bind(const P1& p1) {
BindState<void(P1)>();
}

class Version;
void CheckPnaclComponentManifest(Version* version_out); // With this line: private. Without: not.

class attribute((visibility("default"))) Version { };

void f() {
Bind(Version());
}

$ Release+Asserts/bin/clang -c repro-weak-private-external.ii -fvisibility=hidden && nm -m repro-weak-private-external.o | grep _Z4BindI7VersionEvRKT
0000000000000020 (__TEXT,__textcoal_nt) weak private external _Z4BindI7VersionEvRKT
0000000000000070 (__TEXT,__eh_frame) weak private external _Z4BindI7VersionEvRKT.eh

Note that the symbol is "weak private external. If the CheckPnaclComponentManifest() line is removed however, it beomces "weak external".

This is (I think) because the CheckPnacl... function decl calls computeCachedProperties() in Type.cpp for the function type, which calls computeCachedProperties() or the argument type. When f() is being compiled, it then uses the cached value, which doesn't know about the explicit visibility yet.

(This prevents the chromium component build from working on mac, see http://crbug.com/113934)

@nico
Copy link
Contributor Author

nico commented Feb 14, 2012

Changing the forward declaration of Version to:

class attribute((visibility("default"))) Version;

always makes the symbol weak external (no private). But requiring this would mean that changing the visibility of a type requires updating all forward declarations of the type, which is a bit unfortunate (and gcc and msvc seem to not require it).

@nico
Copy link
Contributor Author

nico commented Feb 15, 2012

gcc4.2 always makes the symbol weak private external.

I guess there's no reason not to – just because Version is visibility("default") doesn't mean that BindState's constructor needs to be default-visible (it's not explicitly marked visible in any form).

@nico
Copy link
Contributor Author

nico commented Feb 17, 2012

half-assed patch
The problem seems to be that the function visibility is set from parameter visibility, which doesn't make much sense. Just because a parameter type is explicitly declared visible, a function taking that type shouldn't become visible.

The attached patch (missing test, comments) fixes this; I'm evaluating it now.

@nico
Copy link
Contributor Author

nico commented Feb 17, 2012

Actually, this patch. (Same idea, though.)

Index: lib/AST/Decl.cpp

--- lib/AST/Decl.cpp (revision 150357)
+++ lib/AST/Decl.cpp (working copy)
@@ -146,6 +146,8 @@
static LinkageInfo getLVForTemplateArgumentList(const TemplateArgument *Args,
unsigned NumArgs,
LVFlags &F) {

  • LinkageInfo TypeLV;

  • //bool oldE = false;
    LinkageInfo LV(ExternalLinkage, DefaultVisibility, false);

    for (unsigned I = 0; I != NumArgs; ++I) {
    @@ -156,7 +158,10 @@
    break;

    case TemplateArgument::Type:

  •  LV.merge(getLVForType(Args[I].getAsType()));
    
  •  TypeLV = getLVForType(Args[I].getAsType());
    
  •  TypeLV.setVisibility(TypeLV.visibility(), false);
    
  •  LV.merge(TypeLV);
     break;
    

    case TemplateArgument::Declaration:

@nico
Copy link
Contributor Author

nico commented Feb 20, 2012

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 23, 2012

Fixed in r151236.

@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

2 participants