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
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: