typeinfo: provide a partial implementation for Win32

[compnerd]

Summary

The RTTI structure is different on Windows when building under MS ABI.
Update the definition to reflect this. The structure itself contains an
area for caching the undecorated name (which is 0-initialized). The
decorated name has a bitfield followed by the linkage name. When
std::type_info::name is invoked for the first time, the runtime should
undecorate the name, cache it, and return the undecorated name. This
requires access to an implementation of __unDName. For now, return
the raw name.

This uses the fnv-1a hash to hash the name of the RTTI. We could use an alternate hash (murmur? city?), but, this was the quickest to throw together.

[majnemer]

src/typeinfo.cpp

28–29

These literals are ill-formed, I think you need a ULL suffix here.

28–32

Why make these static? Seems strange to use that storage duration.

[compnerd]

src/typeinfo.cpp

28–32

Oh, just to ensure that they are handled as literal constants. I can drop the static if you like, since the compiler should do the right thing anyways.

[compnerd]

Add suffixes

[EricWF]

I would really rather see a single definition of the typeinfo class between all platforms, but I see how that could get messy. How about instead of declaring a new one we use the existing class definition, but move all of the method definitions out-of-line and then define them in their own #ifdef blocks?

[EricWF]

Stealing this revision to update with the requested style changes: @compnerd please steal this back.

[EricWF]

Update with the prefered style changes. @compnerd please still this revision back when ready.

[compnerd]

Ill use this version for the commit, but Id like to get an okay on it before I do that :-).

[rnk]

include/typeinfo

75

Is _WIN32 the right condition? It seems like this is intended to match the MS ABI RTTI structure, not the Itanium one. _MSC_VER maybe?

src/typeinfo.cpp

28–32

Isn't constexpr const redundant?

[compnerd]

include/typeinfo

75

Yeah, this is meant to match the MS ABI RTTI. Yeah, _MSC_VER seems more appropriate than _WIN32.

src/typeinfo.cpp

28–32

Yeah, intentional. I should be using _LIBCPP_CONSTEXPR just incase the compiler doesn't support constexpr.

[EricWF]

include/typeinfo

75

I agree. Please make this change before committing.

193

This constructor is almost certainly not correct. @compnerd do you know what constructor call clang-cl generates to construct type_info?

src/typeinfo.cpp

28–32

All supported compiler provide constexpr when building the dylib, so you can assume we have it.

I have no strong objection to the redundancy, but I'm not opposed to removing either const or constexpr.

[EricWF]

This isn't applying against master. Could you rebase?

include/typeinfo

109

Don't we need a constructor here?

[EricWF]

Nevermind. Missed the dependency. Would you be willing to kill that dependency for now and we can fix it once we get Clang support?

[compnerd]

Rebase for r291329.

[compnerd]

include/typeinfo

109

No, we do not need a constructor since the emitted object is already a well formed object instance.

[smeenai]

Rebase

[smeenai]

Rebased and tested on Windows again.

I'd like to see this patch get through to reduce the dependencies on the vcruntime headers, since those end up pulling in lots of cruft and can cause some nasty conflicts. (Similarly, I'll be trying to remove dependencies on Windows.h, which is an evil, evil header.)

There's a behavior difference between this implementation and vcruntime's, since this one doesn't demangle the type name. Idk how much that difference matters in practice though, and I think it's fine to address in a follow-up.

What else needs to be addressed before this is good to go?

include/typeinfo

109

I believe @EricWF was referring to the internal constructors that take a const char *. Do we need one of those for the Microsoft typeinfo?

[compnerd]

I'm happy to pick this up again. LMK what needs to be addressed. AFAIK, no constructors will be invoked as the class is just a wrapper over static data so we don't need the constructors. I would rather do the undecorating stuff in a follow-up.

[smeenai]

@compnerd, @EricWF and I discussed this a bit on IRC yesterday.

My motivation here is that I'm using libc++ with other headers that clash badly with the vcruntime headers, which prevents me from using libc++'s _LIBCPP_ABI_MICROSOFT support. Reducing libc++'s dependencies on the vcruntime headers enables me to at least use parts of the Microsoft ABI support.

At the same time, @EricWF pointed out that most people will expect libc++ to play nicely with the vcruntime headers. In particular, vcruntime_new.h ends up getting pulled in from all sorts of places, which is why libc++ defers to that header instead of trying to provide its own new/delete declarations for _LIBCPP_ABI_MICROSOFT.

One option would be an alternate ABI configuration, which is basically "Microsoft ABI support without reliance on and interoperability with vcruntime headers". Another possibility would be for the libc++ headers to provide vcruntime-compatible declarations for _LIBCPP_ABI_MICROSOFT, which would allow us to remain compatible with the vcruntime headers without depending on them. I find the second option to be cleaner conceptually and would prefer it.

In this particular case, however, I don't believe those concerns apply. vcruntime_typeinfo.h is only pulled in from MSVC's typeinfo header, so it's not going to get pulled in unless explicitly requested, and therefore there are no interoperability concerns. Additionally, the type_info structure here is completely compatible with the one from the vcruntime headers, since they both model the Microsoft ABI typeinfo structure. The only behavior difference is that vcruntime's implementation will demangle the type name, whereas this one won't, but we can address that in a follow-up. In other words, I believe this change can go in independent of whatever decision we reach for vcruntime interoperability in the general case.

[EricWF]

• List Item

In D28212#871034, @smeenai wrote:

@compnerd, @EricWF and I discussed this a bit on IRC yesterday.

In this particular case, however, I don't believe those concerns apply. vcruntime_typeinfo.h is only pulled in from MSVC's typeinfo header, so it's not going to get pulled in unless explicitly requested, and therefore there are no interoperability concerns. Additionally, the type_info structure here is completely compatible with the one from the vcruntime headers, since they both model the Microsoft ABI typeinfo structure. The only behavior difference is that vcruntime's implementation will demangle the type name, whereas this one won't, but we can address that in a follow-up. In other words, I believe this change can go in independent of whatever decision we reach for vcruntime interoperability in the general case.

I'm convinced. Kill away.

This patch LGTM other than the mentioned nits.

include/typeinfo

95

Perhaps the struct should have a different name than the instance of it.

100

These should probably have _LIBCPP_FUNC_VIS visibility declarations attached to them.

101

Is there a reason why __name and __hash need wrappers? Can't we just provide out-of-line definitions for name() and hash_code() directly?

200

Comment on #endif please.

[EricWF]

Woops. didn't mean to reject.

[compnerd]

include/typeinfo

100

Wont bother due to out-of-line definition

101

I don't remember why ... we can address that when we hit it. Going to out-of-line them.

109

No, no such constructor is needed with MS ABI AFAIK. Construction of the type does not invoke a constructor and libc++ does not create instances of this.

200

Sure!

src/typeinfo.cpp

28–32

Removed static and const.

[smeenai]

include/typeinfo

100

Drop the struct; it causes compilation errors.

This needs to be marked const.

src/typeinfo.cpp

15

Drop the struct and add the const.

21

You need a const here.

36

The -> should be .

[compnerd]

Also added _NOEXCEPT to __compare.

[compnerd]

SVN r313344

include/typeinfo

 #pragma GCC system_header
 #endif
 
-#if defined(_LIBCPP_ABI_MICROSOFT)
-#include <vcruntime_typeinfo.h>
-#elif defined(_LIBCPP_NONUNIQUE_RTTI_BIT)
+#if !defined(_LIBCPP_ABI_MICROSOFT)
+#if defined(_LIBCPP_NONUNIQUE_RTTI_BIT)
 #define _LIBCPP_HAS_NONUNIQUE_TYPEINFO
 #else
 #define _LIBCPP_HAS_UNIQUE_TYPEINFO
 #endif
+#endif
 
 namespace std  // purposefully not using versioning namespace
 {
 
-#if !defined(_LIBCPP_ABI_MICROSOFT)
 class _LIBCPP_EXCEPTION_ABI type_info
 {
     type_info& operator=(const type_info&);

     { return __builtin_strcmp(name(), __arg.name()); }
 #endif
 
+#if defined(_LIBCPP_ABI_MICROSOFT)
+    mutable struct {
+      const char *__undecorated_name;
+      const char __decorated_name[1];
+    } __data;
+
+    int __compare(const struct type_info &__rhs);
+#endif // _LIBCPP_ABI_MICROSOFT
+
 protected:
+#if !defined(_LIBCPP_ABI_MICROSOFT)
 #if defined(_LIBCPP_HAS_NONUNIQUE_TYPEINFO)
     // A const char* with the non-unique RTTI bit possibly set.
     uintptr_t __type_name;

     _LIBCPP_INLINE_VISIBILITY
     explicit type_info(const char* __n) : __type_name(__n) {}
 #endif
+#endif // ! _LIBCPP_ABI_MICROSOFT
 
 public:
     _LIBCPP_AVAILABILITY_TYPEINFO_VTABLE
     virtual ~type_info();
 
+#if defined(_LIBCPP_ABI_MICROSOFT)
+    const char *name() const _NOEXCEPT;
+
+    _LIBCPP_INLINE_VISIBILITY
+    bool before(const type_info& __arg) const _NOEXCEPT {
+      return __compare(__arg) < 0;
+    }
+
+    size_t hash_code() const _NOEXCEPT;
+
+    _LIBCPP_INLINE_VISIBILITY
+    bool operator==(const type_info& __arg) const _NOEXCEPT {
+      return __compare(__arg) == 0;
+    }
+#else
 #if defined(_LIBCPP_HAS_NONUNIQUE_TYPEINFO)
     _LIBCPP_INLINE_VISIBILITY
     const char* name() const _NOEXCEPT

     bool operator==(const type_info& __arg) const _NOEXCEPT
     { return __type_name == __arg.__type_name; }
 #endif
+#endif // _LIBCPP_ABI_MICROSOFT
 
     _LIBCPP_INLINE_VISIBILITY
     bool operator!=(const type_info& __arg) const _NOEXCEPT

     virtual const char* what() const _NOEXCEPT;
 };
 
-#endif // !_LIBCPP_ABI_MICROSOFT
-
 }  // std
 
 _LIBCPP_BEGIN_NAMESPACE_STD

src/support/runtime/exception_msvc.ipp

     return "bad_array_length";
 }
 
+bad_cast::bad_cast() _NOEXCEPT
+{
+}
+
+bad_cast::~bad_cast() _NOEXCEPT
+{
+}
+
+const char *
+bad_cast::what() const _NOEXCEPT
+{
+  return "std::bad_cast";
+}
+
+bad_typeid::bad_typeid() _NOEXCEPT
+{
+}
+
+bad_typeid::~bad_typeid() _NOEXCEPT
+{
+}
+
+const char *
+bad_typeid::what() const _NOEXCEPT
+{
+  return "std::bad_typeid";
+}
+
 } // namespace std

src/typeinfo.cpp

 
 #include "typeinfo"
 
+#if defined(_LIBCPP_ABI_MICROSOFT)
+#include <string.h>
+
+int std::type_info::__compare(const struct type_info &__rhs) {
+  if (&__data == &__rhs.__data)
+    return 0;
+  return strcmp(&__data.__decorated_name[1], &__rhs.__data.__decorated_name[1]);
+}
+
+const char *std::type_info::name() _NOEXCEPT {
+  // TODO(compnerd) cache demangled &__data.__decorated_name[1]
+  return &__data.__decorated_name[1];
+}
+
+size_t std::type_info::hash_code() const _NOEXCEPT {
+#if defined(_WIN64)
+  constexpr size_t fnv_offset_basis = 14695981039346656037ull;
+  constexpr size_t fnv_prime = 10995116282110ull;
+#else
+  constexpr size_t fnv_offset_basis = 2166136261ull;
+  constexpr size_t fnv_prime = 16777619ull;
+#endif
+
+  size_t value = fnv_offset_basis;
+  for (const char* c = &__data->__decorated_name[1]; *c; ++c) {
+    value ^= static_cast<size_t>(static_cast<unsigned char>(*c));
+    value *= fnv_prime;
+  }
+
+#if defined(_WIN64)
+  value ^= value >> 32;
+#endif
+
+  return value;
+}
+#endif // _LIBCPP_ABI_MICROSOFT
+
 // FIXME: Remove __APPLE__ default here once buildit is gone.
-#if (!defined(_LIBCPP_ABI_MICROSOFT) && !defined(LIBCXX_BUILDING_LIBCXXABI) && \
-    !defined(LIBCXXRT) && !defined(__GLIBCXX__) && \
-    !defined(__APPLE__)) || \
-    defined(_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY) // FIXME: remove this configuration.
+// FIXME: Remove the _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY configuration.
+#if (!defined(LIBCXX_BUILDING_LIBCXXABI) && !defined(LIBCXXRT) &&              \
+     !defined(__GLIBCXX__) && !defined(__APPLE__)) ||                          \
+    defined(_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY)
 std::type_info::~type_info()
 {
 }