smeenai created this revision. smeenai added reviewers: compnerd, EricWF, mclow.lists. smeenai added a subscriber: cfe-commits.
The behavior of this macro actually needs to apply universally on Windows and not just when using the Microsoft CRT. Update the macro definition and documentation accordingly. https://reviews.llvm.org/D25145 Files: docs/DesignDocs/VisibilityMacros.rst include/new Index: include/new =================================================================== --- include/new +++ include/new @@ -125,7 +125,7 @@ } // std -#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY) +#if defined(_WIN32) && !defined(_LIBCPP_BUILDING_LIBRARY) # define _LIBCPP_NEW_DELETE_VIS #else # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS Index: docs/DesignDocs/VisibilityMacros.rst =================================================================== --- docs/DesignDocs/VisibilityMacros.rst +++ docs/DesignDocs/VisibilityMacros.rst @@ -112,14 +112,15 @@ Mark a symbol as being exported by the libc++ library. This macro must be applied to all `operator new` and `operator delete` overloads. - **Windows Behavior**: When using the Microsoft CRT, all the `operator new` and - `operator delete` overloads are defined statically in `msvcrt.lib`. Marking - them as `dllimport` in the libc++ `<new>` header is therefore undesirable: if - we were to mark them as `dllimport` and then link against libc++, source files - which included `<new>` would end up linking against libc++'s `operator new` - and `operator delete`, while source files which did not include `<new>` would - end up linking against msvcrt's `operator new` and `operator delete`, which - would be a confusing and potentially error-prone inconsistency. + **Windows Behavior**: The `operator new` and `operator delete` overloads + should not be marked as `dllimport`; if they were, source files including the + `<new>` header (either directly or transitively) would lose the ability to use + local overloads of `operator new` and `operator delete`. On Windows, this + macro therefore expands to `__declspec(dllexport)` when building the library + and has an empty definition otherwise. A related caveat is that libc++ must be + included on the link line before `msvcrt.lib`, otherwise Microsoft's + definitions of `operator new` and `operator delete` inside `msvcrt.lib` will + end up being used instead of libc++'s. Links =====
Index: include/new =================================================================== --- include/new +++ include/new @@ -125,7 +125,7 @@ } // std -#if defined(_LIBCPP_MSVCRT) && !defined(_LIBCPP_BUILDING_LIBRARY) +#if defined(_WIN32) && !defined(_LIBCPP_BUILDING_LIBRARY) # define _LIBCPP_NEW_DELETE_VIS #else # define _LIBCPP_NEW_DELETE_VIS _LIBCPP_FUNC_VIS Index: docs/DesignDocs/VisibilityMacros.rst =================================================================== --- docs/DesignDocs/VisibilityMacros.rst +++ docs/DesignDocs/VisibilityMacros.rst @@ -112,14 +112,15 @@ Mark a symbol as being exported by the libc++ library. This macro must be applied to all `operator new` and `operator delete` overloads. - **Windows Behavior**: When using the Microsoft CRT, all the `operator new` and - `operator delete` overloads are defined statically in `msvcrt.lib`. Marking - them as `dllimport` in the libc++ `<new>` header is therefore undesirable: if - we were to mark them as `dllimport` and then link against libc++, source files - which included `<new>` would end up linking against libc++'s `operator new` - and `operator delete`, while source files which did not include `<new>` would - end up linking against msvcrt's `operator new` and `operator delete`, which - would be a confusing and potentially error-prone inconsistency. + **Windows Behavior**: The `operator new` and `operator delete` overloads + should not be marked as `dllimport`; if they were, source files including the + `<new>` header (either directly or transitively) would lose the ability to use + local overloads of `operator new` and `operator delete`. On Windows, this + macro therefore expands to `__declspec(dllexport)` when building the library + and has an empty definition otherwise. A related caveat is that libc++ must be + included on the link line before `msvcrt.lib`, otherwise Microsoft's + definitions of `operator new` and `operator delete` inside `msvcrt.lib` will + end up being used instead of libc++'s. Links =====
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits