Type normalisation in embind

[mejedi]

IRT marshalling, T, T& and const/volatile variants of T and T& are effectively the same.

Embind refuses to marshall volatile–qualified objects, so let's forget them for the time being. (Fails with an odd error message in emscripten/val.h.)

There are two parts to marshalling: emscripten::internal::BindingType<T> providing toWireType()/fromWireType() and emscripten::internal::TypeID<T>, providing the type ID.

In the set of BindingType<T> overloads, there are overloads reducing const T -> T, T& -> T and so forth.

There's no such normalisation for TypeID<T>. Due to the lack of normalisation, certain features fail in corner cases. For instance, embind normally refuses to pass raw pointers around, the check implemented as TypeID overload. However:

using namespace emscripten;

// Fails as expected at compile time
val::global("console").call<void>("log", static_cast<void *>(nullptr));

void *p = nullptr;
val::global("console").call<void>("log", p); // Actually compiles!

The normalisation for type ID-s is actually performed, but at a lower level: depending on compile options, it is either typeid() operator, or in LightTypeID.

Proposal

Perform normalisation for TypeID the same way it's done for BindingType<T> (add template specialisations).

[kripken]

cc @chadaustin

[chadaustin]

@mejedi That seems reasonable to me. Want to take a shot at a pull request?

[yeputons]

@chadaustin I've tried fixing this in my branch, but it looks like some tests rely on being able to pass raw pointers to val's constructor (like in #7084), e.g. here.

Looks like at least some special treatment of raw pointers is required, what do you think? val() currently uses the same mechanism as bind.h

[chadaustin]

I feel like passing pointers should val should work (or not work) exactly the same way a function that returns a pointer should work (or not work). I would prefer val's constructor take a raw pointer policy in that case.

Looks like that test was introduced in #4992 cc @AlexPerrot

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.