aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Object/MachOObjectFile.cpp
diff options
context:
space:
mode:
authorShoaib Meenai <smeenai@fb.com>2016-09-28 22:28:51 +0000
committerShoaib Meenai <smeenai@fb.com>2016-09-28 22:28:51 +0000
commit3888eb66b004c0d4701330c8097566a734c4aec1 (patch)
tree07e2c4c7bc02b70d8c0a0e82eef521c8af3c07c1 /llvm/lib/Object/MachOObjectFile.cpp
parent40cbc27ff398b425c3dde1270cadd39d7ef9c5bf (diff)
downloadllvm-3888eb66b004c0d4701330c8097566a734c4aec1.zip
llvm-3888eb66b004c0d4701330c8097566a734c4aec1.tar.gz
llvm-3888eb66b004c0d4701330c8097566a734c4aec1.tar.bz2
[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
Diffstat (limited to 'llvm/lib/Object/MachOObjectFile.cpp')
0 files changed, 0 insertions, 0 deletions