[libcxx-commits] [PATCH] D158450: [libcxx] Provide set_new_handler/get_new_handler on Windows

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added a comment.

I see that the CI build pointed out a bunch of practical issues:

- The DLL build fails with errors like this:

  include\c++\v1\new(170,39): error: redeclaration of 'std::set_new_handler' should not add 'dllexport' attribute [-Werror,-Wdll-attribute-on-redeclaration]
  _LIBCPP_EXPORTED_FROM_ABI new_handler set_new_handler(new_handler) _NOEXCEPT;
                                        ^
  C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt\new.h(32,42): note: previous declaration is here
              _CRTIMP2 new_handler __cdecl set_new_handler(_In_opt_ new_handler _NewHandler) throw();
                                           ^

- The test `llvm-libc++-static-clangcl.cfg.in :: std/language.support/support.dynamic/alloc.errors/set.new.handler/get_new_handler.pass.cpp` which previously was XFAILed no longer fails. This is good at least :-)
- A bunch of tests in `std/language.support/support.dynamic/new.delete/new.delete.{single,array}` fail. I would guess that the issue is that we get the various instances of `operator new` from vcruntime, and on failures, vcruntime calls the preexisting new handler from there, instead of the new one we provide in libc++. I guess that means that unless we move to provide all `operator new` ourselves, we'd need to build on top of msvcprt's `_set_new_handler` like STL does.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158450/new/

https://reviews.llvm.org/D158450