- User Since
- Jun 26 2014, 12:44 PM (195 w, 1 d)
Thu, Mar 22
Uploading correct diff. Sorry for the spam.
- Correct AllocationFnData for align_val_t overloads to properly check the second parameter.
- Add support for nothrow aligned now/delete operators.
Wed, Mar 21
- Launder types with subobjects of dynamic class type.
- Improve diagnostic selection using llvm::Optional<unsigned>.
- Add comment about LTO ABI concerns to test file.
- Merge with master.
- Merge with upstream.
- Add requested assertion.
Fri, Mar 9
Mon, Mar 5
I think the correct fix is something like this: https://github.com/llvm-mirror/libcxx/commit/6878e852d1d26cca0abee3013822311cd894ca3e
Feb 19 2018
I'm fine with this, but I don't really think it's a good solution (but none of our LIT config is ideal). In particular for the link flags might not work well, because the order of linker flags matters a lot and this doesn't really deal with that. But if it works for your case.
Feb 14 2018
Feb 13 2018
LGTM except the removal of the test. I think it's probably valuable to keep around on platforms that allow it.
Feb 12 2018
Feb 11 2018
Committed as r324853.
So my main concern with this patch is that nullptr is actually #defined'ed in C++03 mode. That definition comes from the __nullptr header, and therefore we would need to add that header to each include which uses it. Which kind of sucks.
Feb 9 2018
@lichray I should have mentioned: Although this header is C++17 only, the bits compiled into the dylib need to compile as C++11 still.
Some initial thoughts.
Committed as r324799.
I think the direction here is OK. Although I really hate allowing bits of libc++ to be "optional". In this case it should be OK, but often it makes the library trickier to maintain -- and these configurations often go untested between releases.
Feb 8 2018
- Complete implementation suggested by @rsmith. The builtins now perform overload resolution to allow calling arbitrary usual allocation/deallocation functions.
- Complete tests.
@rsmith. Sorry, you're right. I didn't notice that we already used _LIBCPP_BUILDING_LIBRARY in libc++abi. I wasn't sure if _BUILDING_LIBRARY changed the linkage or of any symbols, or changed their explicit instantiation.
And, indeed, on Windows there's a problem with DLL import/export macros. I'll fix and cleanup the usage of _BUILDING_LIBRARY in the next couple days.
Feb 7 2018
@rsmith Is this the direction you were thinking?
I agree with Marshall. This should define _LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS instead of _LIBCPP_BUILDING_LIBRARY. Other than that, this LGTM.
- Rebase off trunk.
- Rebase off master.
Accepting new version.
- Update with new, hopefully working, version.
This was reverted as it caused build failures. Re-opening with new version.
- Fix documentation as requested.
- Put entire statement inside of #ifdef blocks.