Skip to content

Bump MSRV to 1.86.0 #11142

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 27, 2025
Merged

Conversation

alexcrichton
Copy link
Member

Coupled with today's release of 1.88.0. Also update our nightly version used in CI to the most recent nightly.

Coupled with today's release of 1.88.0. Also update our nightly version
used in CI to the most recent nightly.
@alexcrichton alexcrichton requested review from a team as code owners June 26, 2025 19:38
@alexcrichton alexcrichton requested review from cfallin and fitzgen and removed request for a team June 26, 2025 19:38
@cfallin cfallin enabled auto-merge June 26, 2025 19:40
@cfallin cfallin added this pull request to the merge queue Jun 26, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 26, 2025
@github-actions github-actions bot added the cranelift Issues related to the Cranelift code generator label Jun 26, 2025
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Jun 27, 2025
This commit removes the configuration knob used during fuzzing to use a
custom host memory which is always unaligned on the host. The original
intention for this was to help catch issues related to alignment in the
x64 backend about, for example, performing unaligned SSE loads correctly
(as opposed to accidentally faulting on unaligned addresses).

As shown in the test failures of bytecodealliance#11142, however, this is technically UB
for other parts of Wasmtime that assume the heap addresses are always
aligned. For example Wasmtime will create safe references in to a GC
heap and GC heaps are also allocated with this same allocator, meaning
that Rust-safe references are unaligned (which is UB).

In practice I'm not aware of any actual issues this configuration option
has ever discovered, and we've otherwise discovered alignment issues via
normal fuzzing as well. Given that I think it's best to just jettison
this entirely and stop trying to support it and/or tweak configuration
to only use it when supported or similar.
@alexcrichton
Copy link
Member Author

Opened #11147 to split out the fix for the test failure.

github-merge-queue bot pushed a commit that referenced this pull request Jun 27, 2025
This commit removes the configuration knob used during fuzzing to use a
custom host memory which is always unaligned on the host. The original
intention for this was to help catch issues related to alignment in the
x64 backend about, for example, performing unaligned SSE loads correctly
(as opposed to accidentally faulting on unaligned addresses).

As shown in the test failures of #11142, however, this is technically UB
for other parts of Wasmtime that assume the heap addresses are always
aligned. For example Wasmtime will create safe references in to a GC
heap and GC heaps are also allocated with this same allocator, meaning
that Rust-safe references are unaligned (which is UB).

In practice I'm not aware of any actual issues this configuration option
has ever discovered, and we've otherwise discovered alignment issues via
normal fuzzing as well. Given that I think it's best to just jettison
this entirely and stop trying to support it and/or tweak configuration
to only use it when supported or similar.
@alexcrichton alexcrichton added this pull request to the merge queue Jun 27, 2025
Merged via the queue into bytecodealliance:main with commit 5fe1c8e Jun 27, 2025
41 checks passed
@alexcrichton alexcrichton deleted the update-rust branch June 27, 2025 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cranelift Issues related to the Cranelift code generator
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants