[libc++] Clarify _LIBCPP_NEW_DELETE_VIS for Windows

Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY,
and clarify why the operator new and delete family of functions are
marked dllexport when building but *not* dllimport when including the
header externally.

The new code is identical to the intent of the old code (and would be
functionally equivalent were cxx_EXPORTS still defined when building
libc++). The overall behavior is not ideal, since Microsoft's operator
new and delete functions will get called instead of libc++'s, but I
think consistently calling msvcrt's functions is better than either
calling msvcrt's or libc++'s functions depending on header inclusion.

Differential Revision: https://reviews.llvm.org/D25042

llvm-svn: 282644

1 files changed, 13 insertions, 0 deletions

diff --git a/libcxx/docs/DesignDocs/VisibilityMacros.rst b/libcxx/docs/DesignDocs/VisibilityMacros.rst
index f7d1400341f..f45d67b17ea 100644
--- a/libcxx/docs/DesignDocs/VisibilityMacros.rst
+++ b/libcxx/docs/DesignDocs/VisibilityMacros.rst
@@ -108,6 +108,19 @@ Visibility Macros
   versioning namespace. This allows throwing and catching some exception types
   between libc++ and libstdc++.
 
+**_LIBCPP_NEW_DELETE_VIS**
+  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.
+
 Links
 =====