-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Adding availability
attribute overrides visibility of symbols
#134151
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
Labels
clang:codegen
IR generation bugs: mangling, exceptions, etc.
Comments
@llvm/issue-subscribers-clang-codegen Author: Konstantin Varlamov (var-const)
Symbols annotated with `__attribute__((availability))` always have default visibility, even if marked with `__attribute__((__visibility__("hidden")))` and compiled with `-fvisibility=hidden`. Self-contained repro (courtesy of @ldionne):
```cpp
// Compile with: clang++ -xc++ - -shared -o a.out -fvisibility=hidden -fvisibility-inlines-hidden
// Check symbols with: nm -omg a.out | c++filt | grep value
template <class T>
struct foo {
__attribute__((__visibility__("hidden")))
__attribute__((availability(macos,strict,introduced=10.13)))
T value() const { return 0; }
};
int f(foo<int> x) {
a.out: 0000000000000408 (__TEXT,__text) weak external foo<int>::value() const
|
ldionne
added a commit
to ldionne/llvm-project
that referenced
this issue
Apr 2, 2025
The _LIBCPP_DISABLE_AVAILABILITY macro was removed in afae1a5 as an intended no-op. It turns out that some projects are making use of that macro to work around a Clang bug with availability annotations that still exists: llvm#134151. Since that Clang bug still hasn't been fixed, I feel that we must sill honor that unfortunate macro until we've figured out how to get rid of it without breaking code.
ldionne
added a commit
to ldionne/llvm-project
that referenced
this issue
Apr 8, 2025
The _LIBCPP_DISABLE_AVAILABILITY macro was removed in afae1a5 as an intended no-op. It turns out that some projects are making use of that macro to work around a Clang bug with availability annotations that still exists: llvm#134151. Since that Clang bug still hasn't been fixed, I feel that we must sill honor that unfortunate macro until we've figured out how to get rid of it without breaking code.
var-const
pushed a commit
that referenced
this issue
May 5, 2025
The `_LIBCPP_DISABLE_AVAILABILITY` macro was removed in afae1a5 as an intended no-op. It turns out that some projects are making use of that macro to work around a Clang bug with availability annotations that still exists: #134151. Since that Clang bug still hasn't been fixed, I feel that we must sill honor that unfortunate macro until we've figured out how to get rid of it without breaking code.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this issue
May 6, 2025
The `_LIBCPP_DISABLE_AVAILABILITY` macro was removed in afae1a5 as an intended no-op. It turns out that some projects are making use of that macro to work around a Clang bug with availability annotations that still exists: llvm/llvm-project#134151. Since that Clang bug still hasn't been fixed, I feel that we must sill honor that unfortunate macro until we've figured out how to get rid of it without breaking code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symbols annotated with
__attribute__((availability))
always have default visibility, even if marked with__attribute__((__visibility__("hidden")))
and compiled with-fvisibility=hidden
. Self-contained repro (courtesy of @ldionne):Running
nm
on the resulting binary shows it containsAnnotating a symbol with availability should not affect its visibility.
Also tracked as rdar://33655115
The text was updated successfully, but these errors were encountered: