I am trying to incorporate this tool into another macro. At first I tried to generate code that used the macro, #[witegen]. However, this seems like an extra step when I can use the underlying parsing methods directly.

This is also particularly useful because I can parse snippets of code that will never need to be compiled. For example, in NEAR's case a contract's impl is transformed to be external functions that initialize the state of the contract and then call the impl's corresponding method. However, the function that it generates has an empty signature and the generated function must deserialize the function arguments from a host function. This is all to say that I want to generate a new function with the args of the function a new struct being passed. (This is how the JS interface will end up passing arguments).

So a long winded way of saying that this new generated function doesn't have a body and would fail to compile. So it is very handy to generate this function only to be parsed by witgen.

I am not attached to the new renaming or any of the structure, but just require being able to access the inner methods for parsing and writing to the target wit file.

Variants with fields are really just a special case of an unnamed field wrapping a record. So this PR adds a record with the name variant-type-name-field-name and transforms the field into an unnamed one.
For example,

enum Foo {
    NamedField { name: String }
}

becomes

variant foo {
    named-field(foo-named-field)
}

record foo-named-field {
    name: string
}

Since wit does not have a map type, this PR add support for encoding HashMap's as a list of tuples of key/value pairs.

See https://github.com/bytecodealliance/wit-bindgen/issues/108

Thanks for the crate!

I wanted to ask if there could be documentation support.

Wit supports only comments and does not differentiate between documentation and code comments. But, when using wit-bindgen to transform to markdown, comments are part of the generated .md and correctly located.

Proposal

I propose to make use of this to pass over documentation comments in Rust as comments (using \\) to the generated .wit file. Code comments in the Rust file would be ignored.

Use case

At the end of the day, the objective is to generate the .wit file that people possibly outside of the Rust world can use, therefore it makes sense to me to generate the documentation also outside of the Rust world.

I do not have experience in this type of macros, but I could do the research if needed.

Also fixes #31.

Also looked into cargo-smart-release. This should work:

cargo smart-release witgen --bump minor --no-changelog --update-crates-index

Add --execute for it to actually do it.

This PR ended up growing in scope. Updated:

• wit-parser

Added:

• use (import statements) and resource (impls, however, they only support functions at this time); interface (trait, but this type is not well supported by wit yet).
• impl's methods now support special attributes. e.g.

impl Foo {
  #[special_attr]
  pub fn foo(){}
}

Becomes

resource foo {
  ///@special_attr
  foo: func()
}

• resolver to pull in wit dependencies from use (still need to test multiple depths, currently okay with one)
• clap-cargo-extra, a new crate a made for dealing with cargo CLI and metadata
• k9 testing library which provides snapshotting

I know you already approved, but if you could just leave a comment that should be enough ;-)

This updates the generated wit to comply with the newest syntax.

• f32/f64 --> float32/float64. (Not sure why this decision was made. Why make it longer?)
• Multi-value returns are now tuples
• Can no longer have recursive type definitions.

run cargo install cargo-witgen In MacOS:

➜  my_wit git:(main) ✗ cargo witgen
error: no such subcommand: `witgen`

I rename ~/.cargo/bin/cargo_witgen to ~/.cargo/bin/cargo-witgen, and then ok.

This creates a new Witgen struct that handles generating the wit string and its output. This way other applications (specifically witme) can use #[clap(flatten)] to inject it into their subcommand.

From the format "spec" there are no spaces between keywords and generics. E.g. list<u8>.

If this was a personal preference then perhaps it's worth adding another CLI option.

Currently this comment is at the top of the final generated wit file. This line could also indicate which version of witgen was used to produce the file.

// This is a generated file by witgen (https://github.com/bnjjj/witgen), please do not edit yourself, you can generate a new one thanks to cargo witgen generate command

https://github.com/bnjjj/witgen/blob/411e1c0c534adb7973619d211b02b8492d4716fc/README.md?plain=1#L28

cargo add --help

returns

error: no such subcommand: `add`

        Did you mean `d`?

Version:

cargo 1.58.0 (7f08ace4f 2021-11-24)

Is this a subcommand you have to install?

This issue outlines the current work in wit-bindgen: https://github.com/bytecodealliance/wit-bindgen/issues/201

They also recently created a 0.1.0 tag for the project. I took this as an opportunity to publish aha-wit-parser, which has the same version just different name. It can be added like so:

wit-parser = { version = "0.1.0", package = "aha-wit-parser" }

• [ ] Add parser as a test dep
• [ ] Update key words and syntax changes
• [ ] Generate a wit AST instead of string

First off, fantastic work! Worked out of the box and am excited to help with the project.

One issue I ran into is trying to generate wit from a dependencies. Within the project worked wonders, but I'm guessing the the cli is only checking the source files of the current project.

Without this, I'm wondering if there is a way to publish the wit with cargo?

Again great work and look forward to getting this in the hands of devs working with NEAR smart contracts!