blob: f45d67b17ea25f7d130278362aa46260498ee511 [file] [log] [blame]
Eric Fiselier49e29672016-09-15 22:27:07 +00001========================
2Symbol Visibility Macros
3========================
4
5.. contents::
6 :local:
7
8Overview
9========
10
11Libc++ uses various "visibility" macros in order to provide a stable ABI in
12both the library and the headers. These macros work by changing the
13visibility and inlining characteristics of the symbols they are applied to.
14
15Visibility Macros
16=================
17
18**_LIBCPP_HIDDEN**
19 Mark a symbol as hidden so it will not be exported from shared libraries.
20
21**_LIBCPP_FUNC_VIS**
22 Mark a symbol as being exported by the libc++ library. This attribute must
23 be applied to the declaration of all functions exported by the libc++ dylib.
24
25**_LIBCPP_INLINE_VISIBILITY**
26 Mark a function as hidden and force inlining whenever possible.
27
28**_LIBCPP_ALWAYS_INLINE**
29 A synonym for `_LIBCPP_INLINE_VISIBILITY`
30
31**_LIBCPP_TYPE_VIS**
32 Mark a type's typeinfo and vtable as having default visibility.
33 `_LIBCPP_TYPE_VIS`. This macro has no effect on the visibility of the
34 type's member functions. This attribute cannot be used on class templates.
35
36 **GCC Behavior**: GCC does not support Clang's `type_visibility(...)`
37 attribute. With GCC the `visibility(...)` attribute is used and member
38 functions are affected.
39
40**_LIBCPP_TYPE_VIS_ONLY**
41 The same as `_LIBCPP_TYPE_VIS` except that it may be applied to templates.
42
43 **Windows Behavior**: DLLs do not support dllimport/export on class templates.
44 The macro has an empty definition on this platform.
45
46 Note: This macro should be renamed `_LIBCPP_TEMPLATE_TYPE_VIS`.
47
48**_LIBCPP_ENUM_VIS**
49 Mark the typeinfo of an enum as having default visibility. This attribute
50 should be applied to all enum declarations.
51
52 **Windows Behavior**: DLLs do not support importing or exporting enumeration
53 typeinfo. The macro has an empty definition on this platform.
54
55 **GCC Behavior**: GCC un-hides the typeinfo for enumerations by default, even
56 if `-fvisibility=hidden` is specified. Additionally applying a visibility
57 attribute to an enum class results in a warning. The macro has an empty
58 definition with GCC.
59
60**_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS**
61 Mark the member functions, typeinfo, and vtable of the type named in
62 a `_LIBCPP_EXTERN_TEMPLATE` declaration as being exported by the libc++ library.
63 This attribute must be specified on all extern class template declarations.
64
65 This macro is used to override the `_LIBCPP_TYPE_VIS_ONLY` attribute
66 specified on the primary template and to export the member functions produced
67 by the explicit instantiation in the dylib.
68
69 **GCC Behavior**: GCC ignores visibility attributes applied the type in
70 extern template declarations and applying an attribute results in a warning.
71 However since `_LIBCPP_TYPE_VIS_ONLY` is the same as `_LIBCPP_TYPE_VIS` the
72 visibility is already correct. The macro has an empty definition with GCC.
73
Shoaib Meenai190994e2016-09-19 18:29:07 +000074 **Windows Behavior**: `extern template` and `dllexport` are fundamentally
75 incompatible *on a template class* on Windows; the former suppresses
76 instantiation, while the latter forces it. Specifying both on the same
77 declaration makes the template class be instantiated, which is not desirable
78 inside headers. This macro therefore expands to `dllimport` outside of libc++
79 but nothing inside of it (rather than expanding to `dllexport`); instead, the
80 explicit instantiations themselves are marked as exported. Note that this
81 applies *only* to extern template *classes*. Extern template *functions* obey
82 regular import/export semantics, and applying `dllexport` directly to the
83 extern template declaration is the correct thing to do for them.
84
85**_LIBCPP_CLASS_TEMPLATE_INSTANTIATION_VIS**
86 Mark the member functions, typeinfo, and vtable of an explicit instantiation
87 of a class template as being exported by the libc++ library. This attribute
88 must be specified on all template class explicit instantiations.
89
90 It is only necessary to mark the explicit instantiation itself (as opposed to
91 the extern template declaration) as exported on Windows, as discussed above.
92 On all other platforms, this macro has an empty definition.
93
Eric Fiselierf8f31c42016-09-16 00:00:48 +000094**_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY**
95 Mark a member function of a class template as hidden and inline except when
96 building the libc++ library where it marks the symbol as being exported by
97 the library.
98
99 This macro is used to maintain ABI compatibility for symbols that have been
100 historically exported by the libc++ library but are now marked inline. It
101 should only be applied to member functions of class templates that are
102 externally instantiated.
103
Eric Fiselier49e29672016-09-15 22:27:07 +0000104**_LIBCPP_EXCEPTION_ABI**
105 Mark the member functions, typeinfo, and vtable of the type as being exported
106 by the libc++ library. This macro must be applied to all *exception types*.
Eric Fiselier991c3542016-09-16 02:51:26 +0000107 Exception types should be defined directly in namespace `std` and not the
108 versioning namespace. This allows throwing and catching some exception types
109 between libc++ and libstdc++.
Eric Fiselier49e29672016-09-15 22:27:07 +0000110
Shoaib Meenai3888eb62016-09-28 22:28:51 +0000111**_LIBCPP_NEW_DELETE_VIS**
112 Mark a symbol as being exported by the libc++ library. This macro must be
113 applied to all `operator new` and `operator delete` overloads.
114
115 **Windows Behavior**: When using the Microsoft CRT, all the `operator new` and
116 `operator delete` overloads are defined statically in `msvcrt.lib`. Marking
117 them as `dllimport` in the libc++ `<new>` header is therefore undesirable: if
118 we were to mark them as `dllimport` and then link against libc++, source files
119 which included `<new>` would end up linking against libc++'s `operator new`
120 and `operator delete`, while source files which did not include `<new>` would
121 end up linking against msvcrt's `operator new` and `operator delete`, which
122 would be a confusing and potentially error-prone inconsistency.
123
Eric Fiselier49e29672016-09-15 22:27:07 +0000124Links
125=====
126
127* `[cfe-dev] Visibility in libc++ - 1 <http://lists.llvm.org/pipermail/cfe-dev/2013-July/030610.html>`_
128* `[cfe-dev] Visibility in libc++ - 2 <http://lists.llvm.org/pipermail/cfe-dev/2013-August/031195.html>`_
129* `[libcxx] Visibility fixes for Windows <http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130805/085461.html>`_