-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wit text format comments encoded in the binary Wasm binary #213
Comments
Thanks for filing this; agreed this is something we should fix and agreed that this is probably a custom section thing. Some initial thoughts on what we might want from a custom section format:
|
I can take a shot at this. Would we expect this specification to be part of this repo? |
I don't believe we currently document the binary encoding of WIT, but my hope, at least, it will be soon (and look more like any other component that simply exports the relevant types); I would assume we would then want to document the comment custom section here too. |
Two thoughts on how this could be accomplished, both of which require defining some unique encoding of the "path" to each item.
I'm not sure either of these is all that great, but I'd be happy to hear feedback / other ideas. |
You mean checking that a package is "sufficiently documented" a la Rust's |
To the "does this belong in this repo/spec" question: I think so, probably as a new .md in As for your first question: I expect we want just one custom section, so yeah, the JSON approach probably makes sense. Half-baked idea: instead of putting the
Oh, no, more like: given a component |
I have some prototype code for this now: bytecodealliance/wasm-tools#1169 The JSON schema ended up being directed a bit by the |
Nice! On first glance, it looks really good. Initially I wasn't sure about documenting Wit-level concepts in the schema, but on second thought it does seem like the right level of abstraction. What's interesting is that the well-formedness predicate of the docs section will end up depending on the encoding-scheme of Wit into component types, which is something we need to specify precisely in any case. Incidentally, we were just talking with @peterhuene about where the |
In the near-term JSON I think is ok but in the long-term I'm not sure if it makes sense. Luke above said:
but I'd call that into question in the sense that I'm not sure what this would be used for? You can't, for example, open up a One point in favor against JSON I think is that I think in the long run it doesn't really provide much benefit over a section defined in the manner of the name section. Even with JSON we'd still have to document a schema which feels similar to the work necessary to define a binary format as well. I also feel that using a custom format would avoid the need to shoehorn everything into JSON whether it fits there or not. To clarify again though I think JSON is fine for now, but I do think we'll want to keep the door open to updates in the future. |
I want to know what the documentation comments in My tool generates |
Another question is whether to save markdown or compiled html format. Benefits of using
|
One of the goals of this feature is to be able to transform the binary encoding back into something equivalent to the input WIT text, which strongly suggests that comments should be preserved ~verbatim. |
This has been discussed. Formally, creating an issue for it.
Currently, we lose comments / docs from Wit text formats when compiling to the binary Wasm component file format. This is especially an issue when publishing to the Warg registry that is designed to only accept Wasm binary files.
Likely implementation would involve some custom section convention.
The text was updated successfully, but these errors were encountered: