[PATCH] More on adding sized deallocation functions in libc++

[Richard Smith]

Remove the `_LIBCPP_BUILDING_NEW` guard. If people want the useless C++14 declarations, they can build in C++14 mode...


================
Comment at: src/new.cpp:134
@@ -133,2 +133,3 @@
 
+#if _LIBCPP_STD_VER >= 14
 _LIBCPP_WEAK _LIBCPP_NEW_DELETE_VIS
----------------
Remove this `#if`/`#endif` pair and define the weak version unconditionally. The contents of the standard library should not depend on the `-std=` flag passed when bulding it. Because this function is weak, this won't break valid C++11 and earlier code that happens to be defining such a function.

================
Comment at: src/new.cpp:164
@@ -161,2 +163,3 @@
 
+#if _LIBCPP_STD_VER >= 14
 _LIBCPP_WEAK _LIBCPP_NEW_DELETE_VIS
----------------
Likewise.

================
Comment at: test/std/language.support/support.dynamic/new.delete/new.delete.array/sized_delete_array.pass.cpp:53
@@ +52,3 @@
+    assert(!delete_nothrow_called);
+    delete [] ap;
+    assert(!A_constructed);
----------------
This is not guaranteed to work; your calls to `operator new` and `operator delete` are elidable. Directly call `operator delete` here. (That also lets you run this test in all language modes, not just C++14 mode.)

================
Comment at: test/std/language.support/support.dynamic/new.delete/new.delete.array/sized_delete_array_nothrow.pass.cpp:29
@@ +28,3 @@
+  ++delete_called;
+  std::free(p);
+}
----------------
It's questionable to assume that memory allocated by libc++'s `operator new` can be freed by `std::free`. I would suggest either replacing `operator new[]` too, or just leaking the memory.

http://reviews.llvm.org/D7707

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/