[libcxx-commits] [PATCH] D58203: [libc++] Inline stdexcept constructors, destructors, and assignment operators when using MSVC ABI

Tom Anderson via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Feb 13 16:24:56 PST 2019


thomasanderson marked an inline comment as not done.
thomasanderson added a comment.

In D58203#1397191 <https://reviews.llvm.org/D58203#1397191>, @EricWF wrote:

> hanks for looping me in. I'm working on a similar problem but with libstdc++.
>
> I think the approach of creating specific visibility macros for the exception / runtime bits than need to be shared makes sense,
>  though the additional complexity is unfortunate.


The visibility macro is only used in one place.  maybe we could just do something like:

  class
  #if defined(_LIBCPP_ABI_INLINE_STDEXCEPT_DEFINITIONS)
  _LIBCPP_TYPE_VIS
  #else
  _LIBCPP_HIDDEN
  #endif
  __libcpp_refstring

wdyt?



================
Comment at: src/include/refstring.h:69
 
-inline
+_LIBCPP_REFSTRING_INLINE_VISIBILITY
 __libcpp_refstring::__libcpp_refstring(const char* msg) {
----------------
EricWF wrote:
> These changes seem wrong. And I don't understand why the changes are needed in relation to MSVC.
This is now needed eg. for the inline definition of logic_error::logic_error(), which must now construct a __libcpp_refstring.

If I leave "inline" in, I get link errors:
    lld-link: error: undefined symbol: "public: __cdecl std::__1::__libcpp_refstring::__libcpp_refstring(char const *)" (??0__libcpp_refstring at __1@std@@QEAA at PEBD@Z)
    >>> referenced by obj/buildtools/third_party/libc++/libc++/string.obj

include/refstring.h gets included in stdexcept.cpp.  Actually, that's the only place it gets included, so maybe we could get rid of the inline altogether since we can't have multiple definitions?


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

https://reviews.llvm.org/D58203





More information about the libcxx-commits mailing list