Stream: git-wasmtime

Topic: wasmtime / Issue #1382 Support sealing blocks created by ...

Wasmtime GitHub notifications bot (Mar 23 2020 at 03:28):

github-actions[bot] commented on Issue #1382:

Subscribe to Label Action

This issue or pull request has been labeled: "cranelift"

<details> <summary>Users Subscribed to "cranelift"</summary>

• @bnjbvr

</details>

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

Learn more.

Wasmtime GitHub notifications bot (Mar 28 2020 at 03:35):

thepowersgang commented on Issue #1382:

I'm wondering if the "correct" option would be to unconditionally seal, and change seal_all_blocks to ignore already-sealed blocks.

Wasmtime GitHub notifications bot (Apr 01 2020 at 07:07):

teapotd commented on Issue #1382:

Yes, I think it would be clearer. It would be a change in public API though. @alexcrichton what do you think?

Wasmtime GitHub notifications bot (Apr 01 2020 at 10:28):

thepowersgang commented on Issue #1382:

Would it be a visible change? Currently seal_all_blocks panics if there's previously-sealed blocks around, would it be a breaking change to make it not do that?

Wasmtime GitHub notifications bot (Apr 01 2020 at 10:31):

bjorn3 commented on Issue #1382:

Technically it is a breaking change, but it is unlikely anyone depends on it. Besides breaking changes are regularly made to Cranelift. For example the change from EBB to BB and adding a TrapSink argument to Module::define_function.

Wasmtime GitHub notifications bot (Apr 01 2020 at 13:56):

alexcrichton commented on Issue #1382:

Sorry I don't know a lot about cranelift myself, so I don't have much advice on idioms/review/etc.

Wasmtime GitHub notifications bot (Apr 02 2020 at 15:12):

teapotd commented on Issue #1382:

Okay, I changed seal_all_blocks to ignore sealed blocks and Switch::emit to always seal generated blocks.

Last updated: Dec 23 2024 at 12:05 UTC