consider emitting the rust api information as json as well

[devoncarew]

In addition to generating bindings for n various languages, it would be useful to emit the rust api information as json. This would allow for some additional use cases w/o having to modify the diplomat generator tool.

For context, I'd like to call into the wasm module compiled from https://github.com/unicode-org/icu4x, but want to recover some of the api information (things like function parameter names and api documention). The wasm module itself contains function names, param types, and return value types.

[robertbastian]

Why JSON? Is there a commonly used schema to describe C APIs? Our C headers are of meant to be this representation, they are the standard file format to describe C APIs and are machine-readable. They are missing documentation at the moment though.

[devoncarew]

Well, two reasons:

• json is much easier to parse then c. there are standard libraries to parse json; for c headers files, I'd have to hand-roll a quick and dirty parser
• I notice that there are a different number of arguments into the c functions than into the ones in the wasm modules. The c functions return a pointer, and the wasm ones expect a buffer as the first arg? a json file could have complete info about the parameters, or at least faithfully represent everything was was present in the original rust

Is there a commonly used schema to describe C APIs?

I wouldn't be to worried about trying to match an existing schema; just providing info like a list of functions, function arg info, and api doc text, would be useful.

[sffc]

I think we want to get to a point where third-party crates can consume diplomat_core::hir. I wouldn't be opposed to dumping that structure out into Serde.

[Manishearth]

I wanted Diplomat's hir to implement ser/de for this reason but never got around to it.

However this would be the regular hir, not "cleaned up" with things like renames applied. Bear in mind different backends see different things when it comes to APIs because of diplomat attributes.

[devoncarew]

However this would be the regular hir, not "cleaned up" with things like renames applied. Bear in mind different backends see different things when it comes to APIs because of diplomat attributes.

Yup, that makes sense. Given the info in any format, I think I could recover it enough for my purposes.

I'll check to make sure that debug builds of the rust -> wasm module don't already contain the names of function params (ala https://webassembly.github.io/spec/core/appendix/custom.html).

[devoncarew]

OK, even when removing the optimization settings and release mode from https://github.com/unicode-org/icu4x/blob/main/ffi/npm/Makefile, I was not able to get the rust toolchain to populate the 'Local Names' section in the wasm module (having all the info self-contained in the wasm module would have been nice).

---

update: it looks like the debug info is being written in DWARF format into custom WASM sections - .debug_info and related.