Merge with upstream #265
Merged
Merge with upstream #265
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Update MSRV to 1.81.0 Coupled with today's release of Rust 1.83 this bumps our MSRV on Wasmtime to 1.81. This also updates the nightly used for testing too. prtest:full * Propagate some necessary features through Winch * Remove std feature from adapter configuration Looks to be historical at this point and is no longer needed
Copyright (c) 2024, Arm Limited. Signed-off-by: Karl Meakin <[email protected]>
* Start using `#[expect]` instead of `#[allow]` In Rust 1.81, our new MSRV, a new feature was added to Rust to use `#[expect]` to control lint levels. This new lint annotation will silence a lint but will itself cause a lint if it doesn't actually silence anything. This is quite useful to ensure that annotations don't get stale over time. Another feature is the ability to use a `reason` directive on the attribute with a string explaining why the attribute is there. This string is then rendered in compiler messages if a warning or error happens. This commit migrates applies a few changes across the workspace: * Some `#[allow]` are changed to `#[expect]` with a `reason`. * Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros). * Some `#[allow]` are removed since the lint doesn't actually fire. * The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions. * Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period. The end-state is that all crates should use `#[expect(..., reason = "...")]` for any lint that unconditionally fires but is expected. The `#[allow(..., reason = "...")]` lint should be used for conditionally firing lints, primarily in macro-related code. The `allow_attributes_without_reason = 'warn'` level is intended to be permanent but the transitionary `#[expect(clippy::allow_attributes_without_reason)]` crate annotations to go away over time. * Fix adapter build prtest:full * Fix one-core build of icache coherence * Use `allow` for missing_docs Work around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn't fixed for our MSRV at this time. * More MSRV compat
* Update to regalloc2 0.11.1. Pulls in a fix for a performance regression related to Rust's new standard library sort function. (This is a semver-compatible upgrade to our existing 0.11.0 dep so should be pulled in by non-locked builds automatically, but let's do it explicitly to set the minimum version and get our vetting data updated too.) * Vetted hashbrown 0.14.15 -> 0.15.2.
* pulley: Implement a new `br_table` instruction This is intended to match WebAssembly's `br_table` and Cranelift's version as well. This is implemented as a new `br_table32` opcode where a 32-bit number of branch targets are encoded after `br_table32` all as a `PcRelOffset`, a 32-bit offset. This helps bake in a more "macro opcode" into the interpreter rather than a handful of more primitive opcodes that would achieve the same result with loads/indirect jumps/comparisons/etc. * Fix disassembling * Update cranelift/codegen/src/isa/pulley_shared/inst.isle Co-authored-by: Andrew Brown <[email protected]> --------- Co-authored-by: Andrew Brown <[email protected]>
* Update some `Config` defaults documentation Indicate that the defaults are based on compilation and target settings and document a few interactions on wasm proposals. Closes bytecodealliance#9694 * Apply suggestions from code review Co-authored-by: Pat Hickey <[email protected]> --------- Co-authored-by: Pat Hickey <[email protected]>
This allows the debugger to find them. After much research, this has been chosen as the overall best solution. The alternative here would be to create machine code thunks that call these symbols when Jitting code, and describing those thunks in DWARF, which would be significantly more complex.
…e#9693) I'm doing some other refactoring which makes it a pain to maintain a list in two locations of what all the host signatures are. Instead remove the pulley `for_each_host_signature!` macro entirely. My thinking is to instead implement a different system for host calls in pulley: * The same relocation-style mechanism is used with some number-embedded-in-the-bytecode. * The interpreter exits with "imma call the host" when it sees this special opcode. * The interpreter embedder, aka Wasmtime, is responsible for then invoking the actual function pointer. * Wasmtime already has static knowledge of all its function signatures, e.g. via various macros. This will prevent the need to list all function signatures twice and risk them getting out of sync. Most of the Pulley-level integration work here is left to a future commit.
Mostly comes with a split in `wasmparser` of simd/other ops since it's now possible to disable the `simd` feature at compile time (which we don't use in Wasmtime right now).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.