{"id":13472706,"url":"https://github.com/bytecodealliance/wit-bindgen","last_synced_at":"2026-02-12T04:23:25.409Z","repository":{"id":37076955,"uuid":"341707514","full_name":"bytecodealliance/wit-bindgen","owner":"bytecodealliance","description":"A language binding generator for WebAssembly interface types","archived":false,"fork":false,"pushed_at":"2025-07-08T22:13:38.000Z","size":14859,"stargazers_count":1200,"open_issues_count":95,"forks_count":227,"subscribers_count":36,"default_branch":"main","last_synced_at":"2025-07-08T23:26:39.251Z","etag":null,"topics":["interface-types","module-linking","rust","wasi","wasmtime","webassembly"],"latest_commit_sha":null,"homepage":"","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/bytecodealliance.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE-APACHE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2021-02-23T22:25:51.000Z","updated_at":"2025-07-08T22:13:41.000Z","dependencies_parsed_at":"2023-10-05T15:32:39.598Z","dependency_job_id":"9f052d27-b308-4ea5-a606-725408d5dea5","html_url":"https://github.com/bytecodealliance/wit-bindgen","commit_stats":{"total_commits":514,"total_committers":53,"mean_commits":9.69811320754717,"dds":0.6147859922178989,"last_synced_commit":"80d9ffaff064092b212bd68339a02e1c2f131416"},"previous_names":[],"tags_count":218,"template":false,"template_full_name":null,"purl":"pkg:github/bytecodealliance/wit-bindgen","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bytecodealliance%2Fwit-bindgen","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bytecodealliance%2Fwit-bindgen/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bytecodealliance%2Fwit-bindgen/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bytecodealliance%2Fwit-bindgen/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/bytecodealliance","download_url":"https://codeload.github.com/bytecodealliance/wit-bindgen/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/bytecodealliance%2Fwit-bindgen/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":264922908,"owners_count":23683705,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["interface-types","module-linking","rust","wasi","wasmtime","webassembly"],"created_at":"2024-07-31T16:00:57.263Z","updated_at":"2026-02-12T04:23:25.402Z","avatar_url":"https://github.com/bytecodealliance.png","language":"Rust","readme":"\u003cdiv align=\"center\"\u003e\n  \u003ch1\u003e\u003ccode\u003ewit-bindgen\u003c/code\u003e\u003c/h1\u003e\n\n  \u003cp\u003e\n    \u003cstrong\u003eGuest language bindings generator for\n    \u003ca href=\"https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md\"\u003eWIT\u003c/a\u003e\n    and the\n    \u003ca href=\"https://github.com/WebAssembly/component-model\"\u003eComponent Model\u003c/a\u003e\n    \u003c/strong\u003e\n  \u003c/p\u003e\n\n\u003cstrong\u003eA \u003ca href=\"https://bytecodealliance.org/\"\u003eBytecode Alliance\u003c/a\u003e project\u003c/strong\u003e\n\n  \u003cp\u003e\n    \u003ca href=\"https://github.com/bytecodealliance/wit-bindgen/actions?query=workflow%3ACI\"\u003e\u003cimg src=\"https://github.com/bytecodealliance/wit-bindgen/workflows/CI/badge.svg\" alt=\"build status\" /\u003e\u003c/a\u003e\n    \u003cimg src=\"https://img.shields.io/badge/rustc-stable+-green.svg\" alt=\"supported rustc stable\" /\u003e\n  \u003c/p\u003e\n\u003c/div\u003e\n\n## About\n\n[zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/327223-wit-bindgen\n\nThis project is a suite of bindings generators for languages that are compiled\nto WebAssembly and use the [component model]. Bindings are described with\n[`*.wit` files][WIT] which specify imports, exports, and facilitate reuse\nbetween bindings definitions.\n\n[WIT]: https://component-model.bytecodealliance.org/design/wit.html\n[component model]: https://github.com/WebAssembly/component-model\n\nThe `wit-bindgen` repository is currently focused on **guest** programs which\nare those compiled to WebAssembly. Languages developed in this repository are\nRust, C, C++, C#, and Go. For other languages see the [documentation\nbelow](#guest-other-languages).\n\nExecuting a component in a host is not\nmanaged in this repository, and some options of how to do so are [described\nbelow][hosts]. If you encounter any problems feel free to [open an\nissue](https://github.com/bytecodealliance/wit-bindgen/issues/new) or chat with\nus on [Zulip][zulip].\n\n## [WIT] as an IDL\n\nThe `wit-bindgen` project extensively uses [WIT] definitions to describe imports\nand exports. The items supported by [WIT] directly map to the component model\nwhich allows core WebAssembly binaries produced by native compilers to be\ntransformed into a component. All imports into a WebAssembly binary and all\nexports must be described with [WIT]. An example file looks like:\n\n```wit\npackage example:host;\n\nworld host {\n  import print: func(msg: string);\n\n  export run: func();\n}\n```\n\nThis describes a \"world\" which describes both imports and exports that the\nWebAssembly component will have available. In this case the host will provide a\n`print` function and the component itself will provide a `run` function.\n\nFunctionality in [WIT] can also be organized into `interface`s:\n\n```wit\npackage example:my-game;\n\ninterface my-plugin-api {\n  record coord {\n    x: u32,\n    y: u32,\n  }\n\n  get-position: func() -\u003e coord;\n  set-position: func(pos: coord);\n\n  record monster {\n    name: string,\n    hp: u32,\n    pos: coord,\n  }\n\n  monsters: func() -\u003e list\u003cmonster\u003e;\n}\n\nworld my-game {\n  import print: func(msg: string);\n  import my-plugin-api;\n\n  export run: func();\n}\n```\n\nHere the `my-plugin-api` interface encapsulates a group of functions, types,\netc. This can then be imported wholesale into the `my-game` world via the\n`my-plugin-api` namespace. The structure of a [WIT] document and world will affect the\ngenerated bindings per-language.\n\nFor more information about WIT and its syntax see the [online documentation for\nWIT][WIT] as well as its [upstream\nreference](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md).\n\n## Creating a Component\n\nThe end-goal of `wit-bindgen` is to facilitate creation of a\n[component][component model]. Once a component is created it can then be handed\noff to any one of a number of [host runtimes][hosts] for execution. Creating a\ncomponent is not supported natively by any language today, however, so\n`wit-bindgen` is only one of the pieces in the process of creating a component.\nThe general outline for the build process of a component for a compiled language\nis:\n\n1. Using `wit-bindgen` source code for the language is generated representing\n   bindings to the specified APIs. This source code is then compiled by the\n   native compiler and used by user-written code as well.\n2. The native language toolchain is used to emit a core WebAssembly module. This\n   core wasm module is the \"meat\" of a component and contains all user-defined\n   code compiled to WebAssembly. The most common native target to use for\n   compilation today is the `wasm32-wasip1` target.\n3. The output core wasm module is transformed into a component using the\n   [`wasm-tools`] project, notably the `wasm-tools component new` subcommand.\n   This will ingest the native core wasm output and wrap the output into the\n   component model binary format.\n\n[`wasm-tools`]: https://github.com/bytecodealliance/wasm-tools\n\nThe precise tooling and commands at each of these steps [differs language by\nlanguage][guests], but this is the general idea. With a component in-hand the\nbinary can then be handed off to [a host runtimes][hosts] for execution.\n\n### Creating components: WASI\n\nAn important consideration when creating a component today is WASI. All current\nnative toolchains for languages which have WASI support are using the\n`wasi_snapshot_preview1` version of WASI. This definition of WASI was made\nwith historical `*.witx` files and is not compatible with the component model.\nThere is, however, a means by which to still create components from modules\nthat are using `wasi_snapshot_preview1` APIs.\n\nThe `wasm-tools component new` subcommand takes an `--adapt` argument which acts\nas a way to polyfill non-component-model APIs, like `wasi_snapshot_preview1`,\nwith component model APIs. The [Wasmtime] runtime publishes [adapter\nmodules][preview1-build] with each release that are suitable to use with\n`--adapt` to implement `wasi_snapshot_preview1` in terms of WASI 0.2. On\nWasmtime's releases page you'll see three modules to choose from:\n\n* [`wasi_snapshot_preview1.command.wasm`] - use this for CLI applications.\n* [`wasi_snapshot_preview1.reactor.wasm`] - use this for applications that don't\n  have a `main` function for example: for example a process that responds to an\n  event.\n* [`wasi_snapshot_preview1.proxy.wasm`] - use this for applications fed into\n  `wasmtime serve` for example.\n\nOnly one adapter is necessary and be sure to look for the [latest\nversions][preview1-build] as well.\n\n[preview1-build]: https://github.com/bytecodealliance/wasmtime/releases/latest\n[wasmtime]: https://github.com/bytecodealliance/wasmtime\n[`wasi_snapshot_preview1.command.wasm`]: https://github.com/bytecodealliance/wasmtime/releases/download/v17.0.0/wasi_snapshot_preview1.command.wasm\n[`wasi_snapshot_preview1.reactor.wasm`]: https://github.com/bytecodealliance/wasmtime/releases/download/v17.0.0/wasi_snapshot_preview1.reactor.wasm\n[`wasi_snapshot_preview1.proxy.wasm`]: https://github.com/bytecodealliance/wasmtime/releases/download/v17.0.0/wasi_snapshot_preview1.proxy.wasm\n\n## Supported Guest Languages\n\n[guests]: #supported-guest-languages\n\nThe `wit-bindgen` project is primarily focused on **guest** languages which are\nthose compiled to WebAssembly. Each language here already has native support for\nexecution in WebAssembly at the core wasm layer (e.g. targets the current [core\nwasm specification](https://webassembly.github.io/spec/)). Brief instructions\nare listed here for each language of how to use it as well.\n\nEach project below will assume the following `*.wit` file in the root of your\nproject.\n\n```wit\n// wit/host.wit\npackage example:host;\n\nworld host {\n  import print: func(msg: string);\n\n  export run: func();\n}\n```\n\n### Guest: Rust\n\nThe Rust compiler since version 1.82 supports a native `wasm32-wasip2` target and can be added to\nany `rustup`-based toolchain with:\n\n```sh\nrustup target add wasm32-wasip2\n```\n\nIn order to compile a wasi dynamic library, the following must be added to the\n`Cargo.toml` file:\n\n```toml\n[lib]\ncrate-type = [\"cdylib\"]\n```\n\nProjects can then depend on `wit-bindgen` by executing:\n\n```sh\ncargo add wit-bindgen\n```\n\nWIT files are currently added to a `wit/` folder adjacent to your `Cargo.toml`\nfile. Example code using this then looks like:\n\n```rust\n// src/lib.rs\n\n// Use a procedural macro to generate bindings for the world we specified in\n// `host.wit`\nwit_bindgen::generate!({\n    // the name of the world in the `*.wit` input file\n    world: \"host\",\n});\n\n// Define a custom type and implement the generated `Guest` trait for it which\n// represents implementing all the necessary exported interfaces for this\n// component.\nstruct MyHost;\n\nimpl Guest for MyHost {\n    fn run() {\n        print(\"Hello, world!\");\n    }\n}\n\n// export! defines that the `MyHost` struct defined below is going to define\n// the exports of the `world`, namely the `run` function.\nexport!(MyHost);\n```\n\nBy using [`cargo expand`](https://github.com/dtolnay/cargo-expand) or `cargo\ndoc` you can also explore the generated code. If there's a bug in `wit-bindgen`\nand the generated bindings do not compile or if there's an error in the\ngenerated code (which is probably also a bug in `wit-bindgen`), you can use\n`WIT_BINDGEN_DEBUG=1` as an environment variable to help debug this.\n\nThis project can then be built with:\n\n```sh\ncargo build --target wasm32-wasip2\n```\n\nThis creates a `./target/wasm32-wasip2/debug/my-project.wasm` file which is suitable to execute in any\ncomponent runtime. Using `wasm-tools` you can inspect the binary as well, for\nexample inferring the WIT world that is the component:\n\n```sh\nwasm-tools component wit ./target/wasm32-wasip2/debug/my-project.wasm\n# world my-component {\n#  import print: func(msg: string)\n#  export run: func()\n# }\n```\n\nwhich in this case, as expected, is the same as the input world.\n\n### Guest: C/C++\n\nSee the [`wit-bindgen` C and C++ Bindings Generator documentation](/crates/c/README.md) for details.\n\nC and C++ code can be compiled for the `wasm32-wasip1` target using the [WASI\nSDK] project. The releases on that repository have precompiled `clang` binaries\nwhich are pre-configured to compile for WebAssembly.\n\n[WASI SDK]: https://github.com/webassembly/wasi-sdk\n\nTo start in C and C++ a `*.c` and `*.h` header file is generated for your\nproject to use. These files are generated with the [`wit-bindgen` CLI\ncommand][cli-install] in this repository.\n\n```sh\nwit-bindgen c ./wit\n# Generating \"host.c\"\n# Generating \"host.h\"\n# Generating \"host_component_type.o\"\n```\n\nSome example code using this would then look like\n\n```c\n// my-component.c\n\n#include \"host.h\"\n\nvoid host_run() {\n    host_string_t my_string;\n    host_string_set(\u0026my_string, \"Hello, world!\");\n\n    host_print(\u0026my_string);\n}\n```\n\nThis can then be compiled with `clang` from the [WASI SDK] and assembled into a\ncomponent with:\n\n```sh\nclang host.c host_component_type.o my-component.c -o my-core.wasm -mexec-model=reactor\nwasm-tools component new ./my-core.wasm -o my-component.wasm\n```\n\nLike with Rust, you can then inspect the output binary:\n\n```sh\nwasm-tools component wit ./my-component.wasm\n```\n\n### Guest C#\n\nTo generate the bindings:\n\n```\nwit-bindgen csharp -w command -r native-aot --generate-stub wit/\n```\n\nNow you create a c# project file:\n\n```\ndotnet new console -o MyApp\ncd MyApp\ndotnet new nugetconfig\n```\n\nIn the `nuget.config` after `\u003cclear /\u003e`make sure you have:\n\n```\n\u003cadd key=\"dotnet-experimental\" value=\"https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-experimental/nuget/v3/index.json\" /\u003e\n\u003cadd key=\"nuget\" value=\"https://api.nuget.org/v3/index.json\" /\u003e\n```\n\nIn the MyApp.csproj add the following to the property group:\n\n```\n\u003cRuntimeIdentifier\u003ewasi-wasm\u003c/RuntimeIdentifier\u003e\n\u003cUseAppHost\u003efalse\u003c/UseAppHost\u003e\n\u003cPublishTrimmed\u003etrue\u003c/PublishTrimmed\u003e\n\u003cInvariantGlobalization\u003etrue\u003c/InvariantGlobalization\u003e\n\u003cSelfContained\u003etrue\u003c/SelfContained\u003e\n\u003cAllowUnsafeBlocks\u003etrue\u003c/AllowUnsafeBlocks\u003e\n\u003cWASI_SDK_PATH\u003epath/to/wasi-sdk\u003c/WASI_SDK_PATH\u003e\n```\n\nAdd the native-aot compiler (substitute `win-x64` for `linux-x64` on Linux):\n\n```\ndotnet add package Microsoft.DotNet.ILCompiler.LLVM --prerelease\ndotnet add package runtime.win-x64.Microsoft.DotNet.ILCompiler.LLVM --prerelease\n```\n\nNow you can build with:\n\n```\ndotnet publish\n```\n\nCheck out [componentize-dotnet](https://github.com/bytecodealliance/componentize-dotnet) for a simplified experience.\n\n### Guest: Go\n\nSee the [wit-bindgen-go README.md](crates/go/README.md) for details and generating and using Go bindings.\n\n### Guest: TinyGo\n\n\u003e[!WARNING]\n\u003eThe TinyGo WIT bindings generator found at the [go.bytecodealliance.org](https://github.com/bytecodealliance/go-modules) is no longer being maintained. It is recommended to migrate to [Guest: Go](#guest-go).\n\n### Guest: Java\n\nThis project historically had some support for\n[TeaVM-WASI](https://github.com/fermyon/teavm-wasi), but it was unmaintained for\na long time and never was at feature parity with other generators, so it was\nremoved. The last commit with support for TeaVM-WASI was\nhttps://github.com/bytecodealliance/wit-bindgen/commit/86e8ae2b8b97f11b73b273345b0e00340f017270.\n\n### Guest: C++-17+\n\nThe cpp crate contains code to generate C++ code which uses the std types\noptional, string, string_view, vector, expected to represent generic\nWIT types.\n\nThis relies on wasi-SDK for guest compilation.\n\n### Guest: MoonBit\n\nMoonBit can be compiled to WebAssembly using [its toolchain](https://moonbitlang.com/download):\n\n```sh\nmoon build --target wasm # --debug to keep symbols\n```\n\nThe generated core wasm will be found under `target/wasm/release/build/gen/gen.wasm` by default. Then you can use `wasm-tools` to componentize the module:\n\n```\nwasm-tools component embed wit target/wasm/release/build/gen/gen.wasm -o target/gen.wasm\nwasm-tools component new target/gen.wasm -o target/gen.component.wasm\n```\n\nYou may use `--gen-dir` to specify which package should be responsible for the exportation. The default is `gen` as mentioned above.\nThis can be useful having one project that exports multiple worlds.\n\nWhen using `wit-bindgen moonbit`, you may use `--derive-show` or `--derive-eq` to derive `Show` or `Eq` traits for all types.\nYou may also use `--derive-error`, which will make types containing `Error` as error types in MoonBit.\n\nYou will find the files to be modified with the name `**/stub.mbt`.\nTo avoid touching the files during regeneration (including `moon.pkg.json` or `moon.mod.json`) you may use `--ignore-stub`.\n\n/!\\ MoonBit is still evolving, so please check out the [Weekly Updates](https://www.moonbitlang.com/weekly-updates/) for any breaking changes or deprecations.\n\n### Guest: Other Languages\n\nA (non-exhaustive) list of other languages known to support components are:\n\n* JavaScript through [componentize-js](https://github.com/bytecodealliance/ComponentizeJS)\n* Python through [componentize-py](https://github.com/bytecodealliance/componentize-py)\n\nSee also\n[The WebAssembly Component Model developer's guide](https://component-model.bytecodealliance.org/language-support.html)\nfor examples of how to build components using various languages.\n\nOther languages such as Ruby, etc, are hoped to be supported one day\nwith `wit-bindgen` or with components in general. It's recommended to reach out\non [zulip] if you're interested in contributing a generator for one of these\nlangauges. It's worth noting, however, that turning an interpreted language into\na component is significantly different from how compiled languages currently\nwork (e.g. Rust or C/C++). It's expected that the first interpreted language\nwill require a lot of design work, but once that's implemented the others can\nideally relatively quickly follow suit and stay within the confines of the\nfirst design.\n\n## CLI Installation\n\n[cli-install]: #cli-installation\n\nTo install the CLI for this tool (which isn't the only way it can be used), run\nthe following cargo command. This will let you generate the bindings for any\nsupported language.\n\n```\ncargo install wit-bindgen-cli\n```\n\nThis CLI **IS NOT** stable and may change, do not expect it to be or rely on it\nbeing stable. Please reach out to us on [zulip] if you'd like to depend on it,\nso we can figure out a better alternative for your use case.\n\n## Host Runtimes for Components\n\n[hosts]: #host-runtimes-for-components\n\nThe `wit-bindgen` project is intended to facilitate in generating a component,\nbut once a component is in your hands the next thing to do is to actually\nexecute that somewhere. This is not under the purview of `wit-bindgen` itself\nbut these are some resources and runtimes which can help you work with\ncomponents:\n\n- Rust: the [`wasmtime` crate](https://docs.rs/wasmtime) is an implementation of\n  a native component runtime that can run any WIT `world`. It additionally comes\n  with a [`bindgen!`\n  macro](https://docs.rs/wasmtime/latest/wasmtime/component/macro.bindgen.html)\n  which acts similar to the `generate!` macro in this repository. This macro\n  takes a [WIT] package as input and generates `trait`-based bindings for the\n  runtime to implement and use.\n\n- JS: the [`jco`] project can be used to execute components in JS\n  either on the web or outside the browser in a runtime such as `node`. This\n  project generates a polyfill for a single concrete component to execute in a\n  JS environment by extracting the core WebAssembly modules that make up a\n  component and generating JS glue to interact between the host and these\n  modules.\n\n- Python: the [`wasmtime`](https://github.com/bytecodealliance/wasmtime-py)\n  project [on PyPI](https://pypi.org/project/wasmtime/) has a `bindgen` mode\n  that works similar to the JS integration. Given a concrete component this will\n  generate Python source code to interact with the component using an embedding\n  of Wasmtime for its core WebAssembly support.\n\n- Ruby: the [`wasmtime-rb`](https://github.com/bytecodealliance/wasmtime-rb)\n  project has initial support for components since\n  [v27](https://github.com/bytecodealliance/wasmtime-rb/releases/tag/v27.0.0).\n\n- Tooling: the [`wasm-tools`] project can be used to inspect and modify\n  low-level details of components. For example as previously mentioned you can\n  inspect the WIT-based interface of a component with `wasm-tools component\nwit`. You can link two components together with `wasm-tools compose` as well.\n\n[`jco`]: https://github.com/bytecodealliance/jco\n\nNote that the runtimes above are generally intended to work with arbitrary\ncomponents, not necessarily only those created by `wit-bindgen`. This is also\nnot necessarily an exhaustive listing of what can execute a component.\n\n## Building and Testing\n\nTo build the cli:\n\n```\ncargo build\n```\n\nLearn more how to run the tests in the [testing document](tests/README.md).\n\n# Versioning and Releases\n\nThis repository's crates and CLI are all currently versioned at `0.X.Y` where\n`Y` is frequently `0` and `X` increases most of the time with publishes. This\nmeans that changes are published as possibly-API-breaking changes as development\ncontinues here.\n\nAlso, this repository does not currently have a strict release cadence. Releases\nare done on an as-needed basis. If you'd like a release done please feel free to\nreach out on [Zulip], file an issue, leave a comment on a PR, or otherwise\ncontact a maintainer.\n\n[Zulip]: https://bytecodealliance.zulipchat.com/\n\nFor maintainers, the release process looks like:\n\n* Go to [this link](https://github.com/bytecodealliance/wit-bindgen/actions/workflows/release-process.yml)\n* Click on \"Run workflow\" in the UI.\n* Use the default `bump` argument and hit \"Run workflow\"\n* Wait for a PR to be created by CI. You can watch the \"Actions\" tab for if\n  things go wrong.\n* When the PR opens, close it then reopen it. Don't ask questions.\n* Review the PR, approve it, then queue it for merge.\n\nThat should be it, but be sure to keep an eye on CI in case anything goes wrong.\n\n# License\n\nThis project is triple licenced under the Apache 2/ Apache 2 with LLVM exceptions/ MIT licences. The reasoning for this is:\n- Apache 2/ MIT is common in the rust ecosystem.\n- Apache 2/ MIT is used in the rust standard library, and some of this code may be migrated there.\n- Some of this code may be used in compiler output, and the Apache 2 with LLVM exceptions licence is useful for this.\n\nFor more details see\n- [Apache 2 Licence](LICENSE-APACHE)\n- [Apache 2 Licence with LLVM exceptions](LICENSE-Apache-2.0_WITH_LLVM-exception)\n- [MIT Licence](LICENSE-MIT)\n\n### Contribution\n\nUnless you explicitly state otherwise, any contribution intentionally submitted\nfor inclusion in this project by you, as defined in the Apache 2/ Apache 2 with LLVM exceptions/ MIT licenses,\nshall be licensed as above, without any additional terms or conditions.\n","funding_links":[],"categories":["Rust","库"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbytecodealliance%2Fwit-bindgen","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbytecodealliance%2Fwit-bindgen","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbytecodealliance%2Fwit-bindgen/lists"}