Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Can not derive from time_get_byname #35326

Open Quuxplusone opened 6 years ago

Quuxplusone commented 6 years ago
Bugzilla Link PR36353
Status NEW
Importance P normal
Reported by Jason Liu (jasonliu.development@gmail.com)
Reported on 2018-02-12 08:06:46 -0800
Last modified on 2018-04-03 17:41:39 -0700
Version unspecified
Hardware PC All
CC eric@efcs.ca, llvm-bugs@lists.llvm.org, mclow.lists@gmail.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
I think this is a valid use case:

#include <locale>
typedef std::char_traits<wchar_t> It;
typedef std::istreambuf_iterator<wchar_t, It> Isit;
struct Mytime : public std::time_get_byname<wchar_t, Isit> {
    Mytime(const char *name, size_t refs)
        : std::time_get_byname<wchar_t, Isit>(name, refs) {}
    };

int main(){
const Mytime t("A",1);
}

When I compile this, I get a bunch of undefined symbols:

  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::do_date_order() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__X() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__c() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__r() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__x() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__am_pm() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__weeks() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__months() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__X() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__c() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__r() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__x() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__am_pm() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__weeks() const", referenced from:
      vtable for Mytime in bb-639bbe.o
  "non-virtual thunk to std::__1::time_get_byname<wchar_t, std::__1::istreambuf_iterator<wchar_t, std::__1::char_traits<wchar_t> > >::__months() const", referenced from:
      vtable for Mytime in bb-639bbe.o

When I look at the header and I saw those functions are marked as "always
inline" and "hidden", any reason why those functions are marked as hidden in
the library?
Quuxplusone commented 6 years ago

I agree this is a valid use case.

Fixing it involves changing the visibility of externally instantiated symbols. I'll need to verify with the vendors that this is an acceptable ABI change. I suspect it should be.