[all-commits] [llvm/llvm-project] 9b40ee: [libc++] Define new/delete in libc++abi only by de...

[Louis Dionne via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46
      https://github.com/llvm/llvm-project/commit/9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46
  Author: Louis Dionne <ldionne at apple.com>
  Date:   2020-10-19 (Mon, 19 Oct 2020)

  Changed paths:
    M libcxx/CMakeLists.txt
    M libcxx/cmake/caches/Apple.cmake
    M libcxx/docs/ReleaseNotes.rst
    M libcxx/lib/abi/CHANGELOG.TXT
    M libcxx/lib/abi/CMakeLists.txt
    M libcxx/lib/abi/x86_64-apple-darwin.v1.abilist
    M libcxx/lib/abi/x86_64-unknown-linux-gnu.v1.abilist
    M libcxx/src/CMakeLists.txt
    M libcxxabi/CMakeLists.txt
    M libcxxabi/src/CMakeLists.txt

  Log Message:
  -----------
  [libc++] Define new/delete in libc++abi only by default

Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).

My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.

Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.

On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.

On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.

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