Stream: git-wasmtime

Topic: wasmtime / PR #10053 winch: Tighten the definition of `Ex...

Wasmtime GitHub notifications bot (Jan 20 2025 at 20:04):

saulecabrera opened PR #10053 from saulecabrera:winch-improve-extend-kinds to bytecodealliance:main:

Some instructions, like the atomic ones, part of the threads proposal, we want to ensure through the type system that only supported extend kinds are passed, that way the emission layer can ignore the extend kind validation at runtime.

This commit divides the existing ExtendKind enum into the signed and unsigned variants, making the definition more amenable to atomic operations.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Jan 20 2025 at 20:04):

saulecabrera requested wasmtime-compiler-reviewers for a review on PR #10053.

Wasmtime GitHub notifications bot (Jan 20 2025 at 20:04):

saulecabrera requested abrown for a review on PR #10053.

Wasmtime GitHub notifications bot (Jan 20 2025 at 21:44):

github-actions[bot] commented on PR #10053:

Subscribe to Label Action

cc @saulecabrera

<details>
This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

• saulecabrera: winch

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Jan 20 2025 at 23:24):

abrown submitted PR review:

@saulecabrera, this makes sense to me. I suspect one additional readability may be to add From implementations to avoid having to wrap up the Signed|UnsignedExtend instances inside ExtendKind in so many places. (Something like impl From<SignedExtend> for ExtendKind and perhaps even fn extend(..., impl Into<ExtendKind>)). But it's up to you whether you want to pursue that refactoring; this is also fine as-is.

Wasmtime GitHub notifications bot (Jan 21 2025 at 00:11):

saulecabrera updated PR #10053.

Wasmtime GitHub notifications bot (Jan 21 2025 at 00:13):

saulecabrera commented on PR #10053:

Thanks for the suggestion @abrown, when with implementing conversions from {Signed|Unsigned}Extend -> ExtendKind

Wasmtime GitHub notifications bot (Jan 21 2025 at 00:16):

saulecabrera updated PR #10053.

Wasmtime GitHub notifications bot (Jan 21 2025 at 00:16):

saulecabrera edited a comment on PR #10053:

Thanks for the suggestion @abrown, went with implementing conversions from {Signed|Unsigned}Extend -> ExtendKind

Wasmtime GitHub notifications bot (Jan 21 2025 at 00:27):

saulecabrera has enabled auto merge for PR #10053.

Wasmtime GitHub notifications bot (Jan 21 2025 at 12:15):

saulecabrera commented on PR #10053:

Hmm the failure is related to cargo vet.

Wasmtime GitHub notifications bot (Jan 21 2025 at 15:50):

alexcrichton merged PR #10053.

Last updated: Jan 24 2025 at 00:11 UTC