proposal: limit flags to 64 labels #370
Comments
ydnar
changed the title
|
Adding an implementation limit of 32 flags makes sense to me, since we could relax it later and there's a good chance noone is actually using >32 flags. Changing the current flattening rules for the [32, 64]-flag case seems like maybe more of a recipe for bugs and accidental incompatibility in the rare case that anyone uses [32, 64] flags. Perhaps then later, when we relax the flag limit based on motivating use cases, we could relax it to a different ABI than is currently proposed. WDYT? |
|
Sure. Is there a mechanism to solicit feedback from community on a change like this? |
|
Beyond discussing it in this repo, for a tweak like this, I suppose the best way to get additional feedback is to land the change and see if anything breaks (that's what nightlies and previews are for). |
|
Bindgen for Rust panics for >128 flags but that's only because As to how to get to that world since it's naturally a breaking change from today I'm not so sure. I wouldn't say that we have a great nigthly-style channel to see the breakage before it happens, folks tend to just get broken and not be able to upgrade a dependency they're using. The best way forward might be to implement a warning in WIT pointing to this issue if folks have >32 flags and if no one comments for awhile we can assume it never comes up and then clamp to 32 with the option of increasing to 64 in the future. |
|
If there is currently no implementation in the wild with (32,64] labels, then changing the flatting rules to an i64 seems possible in the short term? |
|
Yeah I'd agree with that myself. I'd be ok either being conservative and limiting it at 32 for a bit or just going straight to 64 with an unconditional single-element flattening. |
|
It's quite possible that literally noone is using >32 flags, so perhaps we could get away with going straight to the goal state without breaking anyone. |
|
I also suspect that noone is using >32 flags. Lets push out this restriction in wasm-tools's validator, and if nobody complains within a month or so, we have confirmed its true. |
This commit is an attempt to explore the design space of WebAssembly/component-model#370. This limits, by default, the number of flags in a component model type to 32 by default. The hope of this issue is to be able to ratchet the maximum number of flags to make it easier on bindings generators to not need to work with arbitrary numbers of flags. The secondary hope is that we can ratchet flags straight to 32 instead of 64 due to it being unlikely that more than 32 flags are in use. Once this percolates there can then be a separate feature for enabling 33-64 flags.
|
I've prototyped this at bytecodealliance/wasm-tools#1635. I'll reiterate that we don't have a great staging mechanism for things like this, so my current plan is:
If no one comments then we're then in a free spot to change things without breaking anyone since no one has 33+ flags. At that point we can change the canonical ABI to allow up to 64 flags and use a single i64 to represent them in flat lowering. If someone comments then I'm hopeful we can find a workaround in the meantime, but that highly depends on specifics. |
* Limit component model flags to 32 This commit is an attempt to explore the design space of WebAssembly/component-model#370. This limits, by default, the number of flags in a component model type to 32 by default. The hope of this issue is to be able to ratchet the maximum number of flags to make it easier on bindings generators to not need to work with arbitrary numbers of flags. The secondary hope is that we can ratchet flags straight to 32 instead of 64 due to it being unlikely that more than 32 flags are in use. Once this percolates there can then be a separate feature for enabling 33-64 flags. * Drop a link
This notably brings in a limitation where component model flags types must have 32 or fewer flags in accordance with the transition plan of WebAssembly/component-model#370. A feature flag is added to go back to the previous behavior to avoid breaking anyone too much. This additionally brings in a fix for a panic when validating invalid modules with tail calls.
This notably brings in a limitation where component model flags types must have 32 or fewer flags in accordance with the transition plan of WebAssembly/component-model#370. A feature flag is added to go back to the previous behavior to avoid breaking anyone too much. This additionally brings in a fix for a panic when validating invalid modules with tail calls.
This notably brings in a limitation where component model flags types must have 32 or fewer flags in accordance with the transition plan of WebAssembly/component-model#370. A feature flag is added to go back to the previous behavior to avoid breaking anyone too much. This additionally brings in a fix for a panic when validating invalid modules with tail calls.
* Update the wasm-tools family of crates This notably brings in a limitation where component model flags types must have 32 or fewer flags in accordance with the transition plan of WebAssembly/component-model#370. A feature flag is added to go back to the previous behavior to avoid breaking anyone too much. This additionally brings in a fix for a panic when validating invalid modules with tail calls. * Add vet entries
* Update the wasm-tools family of crates This notably brings in a limitation where component model flags types must have 32 or fewer flags in accordance with the transition plan of WebAssembly/component-model#370. A feature flag is added to go back to the previous behavior to avoid breaking anyone too much. This additionally brings in a fix for a panic when validating invalid modules with tail calls. * Add vet entries
* Update the wasm-tools family of crates This notably brings in a limitation where component model flags types must have 32 or fewer flags in accordance with the transition plan of WebAssembly/component-model#370. A feature flag is added to go back to the previous behavior to avoid breaking anyone too much. This additionally brings in a fix for a panic when validating invalid modules with tail calls. * Add vet entries
|
This change will be released with Wasmtime 23 happening this weekend. (gating to 32 flags by default). There's an opt-in to enable the old support for 33+ flags if it's encountered though. |
|
PR to update Binary.md/CanonicalABI.md to match in #379. |
[](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [wasmtime](https://github.com/bytecodealliance/wasmtime) | workspace.dependencies | major | `23.0.0` -> `24.0.0` | | [wasmtime-wasi](https://github.com/bytecodealliance/wasmtime) | workspace.dependencies | major | `23.0.0` -> `24.0.0` | --- ### Release Notes <details> <summary>bytecodealliance/wasmtime (wasmtime)</summary> ### [`v24.0.0`](https://github.com/bytecodealliance/wasmtime/releases/tag/v24.0.0) [Compare Source](https://github.com/bytecodealliance/wasmtime/compare/v23.0.2...v24.0.0) ##### 24.0.0 Released 2024-08-20. ##### Added - A new `wasmtime_engine_clone` function was added to the C API. [#​8907](https://github.com/bytecodealliance/wasmtime/pull/8907) - Wasmtime now has basic support for allocating a `StructRef` in the embedder API. [#​8933](https://github.com/bytecodealliance/wasmtime/pull/8933) - The `wasmtime run` subcommand now support a `--argv0` flag indicating the value of the first element to arguments reported to wasm if it shouldn't be the default of the wasm binary name itself. [#​8961](https://github.com/bytecodealliance/wasmtime/pull/8961) - Support for Winch on AArch64 continued to improve. [#​8921](https://github.com/bytecodealliance/wasmtime/pull/8921) [#​9018](https://github.com/bytecodealliance/wasmtime/pull/9018) [#​9033](https://github.com/bytecodealliance/wasmtime/pull/9033) [#​9051](https://github.com/bytecodealliance/wasmtime/pull/9051) - An initial implementation of the `wasi-runtime-config` proposal was added to Wasmtime. [#​8950](https://github.com/bytecodealliance/wasmtime/pull/8950) [#​8970](https://github.com/bytecodealliance/wasmtime/pull/8970) [#​8981](https://github.com/bytecodealliance/wasmtime/pull/8981) - Initial support for f16 and f128 in Cranelift continued to improve. [#​8893](https://github.com/bytecodealliance/wasmtime/pull/8893) [#​9045](https://github.com/bytecodealliance/wasmtime/pull/9045) - More types in `wasmtime-wasi-http` implement the `Debug` trait. [#​8979](https://github.com/bytecodealliance/wasmtime/pull/8979) - The `wasmtime explore` subcommand now supports exploring CLIF too. [#​8972](https://github.com/bytecodealliance/wasmtime/pull/8972) - Support for SIMD in Winch has begun, but it is not complete yet. [#​8990](https://github.com/bytecodealliance/wasmtime/pull/8990) [#​9006](https://github.com/bytecodealliance/wasmtime/pull/9006) - Initial work on Pulley, an interpreter for Wasmtime, has begun. [#​9008](https://github.com/bytecodealliance/wasmtime/pull/9008) [#​9013](https://github.com/bytecodealliance/wasmtime/pull/9013) [#​9014](https://github.com/bytecodealliance/wasmtime/pull/9014) - The `-Wunknown-imports-trap` flag to `wasmtime run` now supports components. [#​9021](https://github.com/bytecodealliance/wasmtime/pull/9021) - An initial implementation of the `wasi-keyvalue` proposal was added to Wasmtime. [#​8983](https://github.com/bytecodealliance/wasmtime/pull/8983) [#​9032](https://github.com/bytecodealliance/wasmtime/pull/9032) [#​9050](https://github.com/bytecodealliance/wasmtime/pull/9050) [#​9062](https://github.com/bytecodealliance/wasmtime/pull/9062) - An `unsafe` API has been added to unload process trap handlers. [#​9022](https://github.com/bytecodealliance/wasmtime/pull/9022) - The s390x backend now fully supports tail calls. [#​9052](https://github.com/bytecodealliance/wasmtime/pull/9052) ##### Changed - The `flags` type in the component model now has a hard limit of 32-or-fewer flags. For more information about this transition [https://github.com/WebAssembly/component-model/issues/370](https://github.com/WebAssembly/component-model/issues/370)sues/370. [#​8882](https://github.com/bytecodealliance/wasmtime/pull/8882) - Multiple returns for functions in the component model are now gated by default and are planned to be removed. [#​8965](https://github.com/bytecodealliance/wasmtime/pull/8965) - TCP streams in WASIp2 will now immediately return `StreamError::Closed` when the TCP stream is closed or shut down. [#​8968](https://github.com/bytecodealliance/wasmtime/pull/8968) [#​9055](https://github.com/bytecodealliance/wasmtime/pull/9055) - Cranelift will now perform constant propagation on some floating-point operations. [#​8954](https://github.com/bytecodealliance/wasmtime/pull/8954) - Wasmtime and Cranelift now require at least Rust 1.78.0 to compile. [#​9010](https://github.com/bytecodealliance/wasmtime/pull/9010) - The `wasmtime::Val` type now implements the `Copy` trait. [#​9024](https://github.com/bytecodealliance/wasmtime/pull/9024) - Wasmtime's wasi-nn implementation has been updated to track the upstream specification. [#​9056](https://github.com/bytecodealliance/wasmtime/pull/9056) - Names provided to `trappable_imports` in `bindgen!` are now validated to be used. [#​9057](https://github.com/bytecodealliance/wasmtime/pull/9057) - Support for multi-package `*.wit` files now requires a `package ...;` header at the top of the file. [#​9053](https://github.com/bytecodealliance/wasmtime/pull/9053) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View the [repository job log](https://developer.mend.io/github/andrzejressel/pulumi-wasm).
](https://renovatebot.com){kind=link}
The current specification for
flagstypes allows an arbitrary (unlimited) number of labels.For languages without a bit vector types or operator overloading (like Go),
flagstypes with <= 64 labels can be represented as an unsigned integer typeu8,u16,u32,u64. Flags can be composed with simple boolean operations, e.g.:f |= FlagFoo. For flags types with > 64 labels, the representation and user-facing API must change to a less ergonomic form. This can be seen in the Canonical ABI flattening rules forflagstypes, which require lowering into a sequence ofi32.If there exist limited or no current or practical applications for
flagswith > 64 labels, I propose we constrainflagstypes to at most 64 labels, and change the Canonical ABI form for types with > 32 and <= 64 labels to ani64.Would changing the flattening rules be a breaking ABI change?
The text was updated successfully, but these errors were encountered: