Add initial (binary only) support for compact imports proposal. NFC.

[sbc100]

See https://github.com/WebAssembly/compact-import-section

This change only adds binary support. Luckily the upstream tests are devided in two seperate
files binary-compact-imports.wast and compact-imports.wast so this change only imports
one of them.

[sbc100]

@tlively or @stevenfontanella how about we land this and I can hand it over to one of your to do the text parse stuff which is beyond my ken.

[sbc100]

I just copied the spec test directly from the upstream repo.. is that the right way to do it, or is there some script / submodule type thing for pulling those in these days?

[stevenfontanella]

I just copied the spec test directly from the upstream repo.. is that the right way to do it, or is there some script / submodule type thing for pulling those in these days?

Looks like it's not in the testsuite repo yet link (I'm not sure when this would happen). Seems ok to me to copy it over for now. Maybe add a TODO to replace it with the one in the testsuite repo once it's there?

how about we land this and I can hand it over to one of your to do the text parse stuff which is beyond my ken.

I'm happy to give it a try!

[stevenfontanella]

Importable doesn't define a virtual destructor, so IIUC we shouldn't put subclasses of Importable in a unique_ptr because deleting it is UB and will leak resources (i.e. this looks like slicing).

Maybe we can just add the virtual destructor? I'm not sure if we didn't add it on purpose to avoid a performance penalty. Or otherwise, maybe we'd want to split these out into different functions for each type of Importable or use a std::variant.

[sbc100]

But I see stuff like std::unique_ptr<Function> all over the codbase.. so isn't "subclasses of Importable in a unique_ptr" just something that exists already?

[sbc100]

Or did you mean we shouldn't put Importable itself in a unique_ptr?

[stevenfontanella]

Yes, unique_ptr<Function> is fine because it will invoke Function's destructor, but an instance of Function in a unique_ptr<Importable> isn't ok because it will invoke Importable's destructor and leak memory (in particular Function has a vector field which has a non-trivial destructor).

It could work if we give the unique_ptr a custom deleter when constructing it, but I feel it would be better to just split these methods into different ones for functions, tables, etc.

[kripken]

A std::variant might also be an option here (but I don't feel strongly one way or the other).

[sbc100]

I see. I guess we don't want to add virtual dtors everywhere to allow this kind of thing?

It does seem kind of backwards to create a std::variant to hold bunch of different things that all share a common supertype. Isn't that exactly what a supertype pointer/reference is supposed to be able to do.

[tlively]

A reasonable solution to the dtor issue might be to have this take T& and return std::unique_ptr<T>, then hoist the switch over kind into the parser code so we never deal with std::unique_ptr<Importable> at all.