This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Get rid of _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS
ClosedPublic

Authored by ldionne on Jun 19 2023, 6:47 AM.

Details

Reviewers
ldionne
Group Reviewers
Restricted Project
Commits
rGafc5cca0d401: [libc++] Get rid of _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS
Summary

Whether we include operator new and delete into libc++ has always
been a build time setting, and piggy-backing on a macro like
_LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS is inconsistent with how
we handle similar cases for e.g. LIBCXX_ENABLE_RANDOM_DEVICE. Instead,
simply avoid including new.cpp in the sources of the library when we
do not wish to include these operators in the build.

This also makes us much closer to being able to share the definitions
between libc++ and libc++abi, since we could technically build those
definitions into a standalone static library and decide whether we link
it into libc++abi.dylib or libc++.dylib.

Diff Detail

Event Timeline

ldionne created this revision.Jun 19 2023, 6:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 19 2023, 6:47 AM
ldionne requested review of this revision.Jun 19 2023, 6:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 19 2023, 6:48 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
philnik added inline comments.
libcxx/src/new.cpp
13

Do you plan to move these conditions into CMake? It seems kind-of weird to just ignore LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS in some cases.

ldionne added inline comments.Jun 20 2023, 7:30 AM
libcxx/src/new.cpp
13

Ideally, I think those should be defined via the CMake cache instead, yeah. Since they also influence what we do for exceptions, I'd like to tackle those independently.

ldionne accepted this revision.Jun 21 2023, 6:01 AM
This revision is now accepted and ready to land.Jun 21 2023, 6:01 AM