Stream: git-wasmtime

Topic: wasmtime / issue #11181 Consider opting-in to more pedant...

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:09):

alexcrichton opened issue #11181:

In light of unsafe code guidelines for Wasmtime and browsing the list of Clippy lints there are a number that we might want to opt-in to. For example:

• missing_safety_doc - this would help ensure that # Safety sections are available on all unsafe functions.
• multiple_unsafe_ops_per_block - this would help ensure that // SAFETY: ... documentation for an unsafe block is accurately describing just one unsafe operation, not multiple by accident. This might also help over time where new unsafety couldn't get introduced in a block by accident without explaining why it's valid.
• undocumented_unsafe_blocks - this would ensure that all unsafe blocks have a comment explaining their rationale.

To be clear though I do not believe that it would be helpful to blanket require this for the workspace all at once. Writing lots of trivial // SAFETY documentation that doesn't do anything more than the obvious is not going to be helpful and will otherwise introduce a lot of noise. Nevertheless though I do think there's a world in which we could perhaps migrate a module-at-a-time to enabling these lints (or maybe even function-at-a-time if modules are too coarse-grained). Over time more and more of the wasmtime crate would be held to a higher standard and eventually the entire crate would use these lints (or some subset).

Wasmtime GitHub notifications bot (Jul 03 2025 at 21:09):

alexcrichton added the wasmtime:unsafe-code label to Issue #11181.

Wasmtime GitHub notifications bot (Oct 12 2026 at 17:05):

ilyas-mallah commented on issue #11181:

Following up from #9402. Point taken that good SAFETY comments need detailed knowledge of the code, so I'd start this only after the Wasmtime part of #9402, once I know this code well. The first PR would be a pilot on code_memory.rs and vm/mmap_vec.rs, and its review would set the level of detail for the rest. After that, vm/mmap.rs with vm/sys/unix/mmap.rs, then vm/cow.rs with pooling/decommit_queue.rs. Each PR adds the SAFETY comments and # Safety docs and enables the three lints for those modules.

Would you or another maintainer be willing to review PRs in that shape? And are these the right modules to start with?

Wasmtime GitHub notifications bot (Oct 12 2026 at 21:00):

alexcrichton commented on issue #11181:

Happy to review, yeah, and I'd recommend starting small, maybe not even an entire file all at once, and then expanding from there.

Last updated: Oct 31 2026 at 23:03 UTC