Skip to content

Require async types when lift/lower uses async#2512

Draft
alexcrichton wants to merge 1 commit intobytecodealliance:mainfrom
alexcrichton:gate-async-on-sync-type
Draft

Require async types when lift/lower uses async#2512
alexcrichton wants to merge 1 commit intobytecodealliance:mainfrom
alexcrichton:gate-async-on-sync-type

Conversation

@alexcrichton
Copy link
Copy Markdown
Member

This is an adjustment to the validation of component-model-async functions and types to correspond to WebAssembly/component-model#646. Specifically when using the async option to lift or lower a function it's now required that the component model type is additionally async. This means, for example, that canon lower of a sync-typed function cannot use the async ABI option. Additionally canon lift cannot use async if the destination component function type is synchronous.

This notably required a number of updates throughout tests. My personal judgement on the required updates here is that everything was originally written without async function types since that didn't exist, then most of these weren't updated, but should have been, once async was added as a function type. In that sense I don't feel these are reflective of real-world breakage, but instead I think it's reflective of the history of the implementation's development.

This is an adjustment to the validation of component-model-async
functions and types to correspond to WebAssembly/component-model#646.
Specifically when using the `async` option to lift or lower a function
it's now required that the component model type is additionally `async`.
This means, for example, that `canon lower` of a sync-typed function
cannot use the `async` ABI option. Additionally `canon lift` cannot use
`async` if the destination component function type is synchronous.

This notably required a number of updates throughout tests. My personal
judgement on the required updates here is that everything was originally
written without `async` function types since that didn't exist, then
most of these weren't updated, but should have been, once `async` was
added as a function type. In that sense I don't feel these are
reflective of real-world breakage, but instead I think it's reflective
of the history of the implementation's development.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant