Changes in trapcode.rs

9fc41bae - Convert `TrapCode` to a single byte (#9338)

Tue, 01 Oct 2024 18:06:33 +0000

Convert `TrapCode` to a single byte (#9338)* Convert `TrapCode` to a single byteThis commit refactors the representation of`cranelift_codegen::ir::TrapCode` to be a single byte. The previousenumeration is replaced with an opaque byte-sized structure. Previousvariants that Cranelift uses internally are now associated `const`values on `TrapCode` itself. For example `TrapCode::IntegerOverflow` isnow `TrapCode::INTEGER_OVERFLOW`. All non-Cranelift traps are nowremoved and exclusively live in the `wasmtime-cranelift` crate now.The representation of a `TrapCode` is now:* 0 - invalid, used in `MemFlags` for "no trap code"* 1..256-N - user traps* 256-N..256 - built-in Cranelift traps (it uses N of these)This enables embedders to have 255-N trap codes which is more thanenough for Wasmtime for example. Cranelift reserves a few built-in codesfor itself which shouldn't eat too much into the trap space.Additionally if Cranelift needs to grow a new trap it can do so prettyeasily too.The overall intent of this commit is to reduce the coupling of Wasmtimeand Cranelift further and generally refactor Wasmtime to use user trapsmore often. This additionally shrinks the size of `TrapCode` for storagein various locations, notably it can now infallibly be representedinside of a `MemFlags`.Closes #9310* Fix some more tests* Fix more tests* Fix even more tests* Review comments* Fix tests* Fix rebase conflict* Update test expectations List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

ec3b2d22 - Implement most `array.*` instructions for the GC proposal (#9326)

Mon, 30 Sep 2024 19:25:35 +0000

Implement most `array.*` instructions for the GC proposal (#9326)* Implement most `array.*` instructions for the GC proposalThis does not implement `array.copy` and `array.init_elem` yet, but implementsall other `array.*` instructions:* `array.new`* `array.new_fixed`* `array.new_default`* `array.new_data`* `array.new_elem`* `array.fill`* `array.init_data`* `array.len`* `array.get`* `array.get_s`* `array.get_u`* `array.set`Note that the initial plumbing for `array.{copy,init_elem}` is in place, but theinstructions themselves are not implemented yet.* Fix no-gc builds* Fix some clippy warnings* cargo fmt* Fix another clippy error* Fix more clippy errors* Remove debug logging* Add array.fill helper* exit scope even on panic List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

05e6a918 - Add the `ArrayOutOfBounds` trap code (#9301)

Tue, 24 Sep 2024 17:51:23 +0000

Add the `ArrayOutOfBounds` trap code (#9301)This is needed in the implementation of Wasm GC's array instructions. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

1dc9b628 - Remove the `NullI31Ref` trap code (#9299)

Tue, 24 Sep 2024 17:06:19 +0000

Remove the `NullI31Ref` trap code (#9299)To precisely match the Wasm spec tests, we would also need `NullStructRef` and`NullArrayRef`, etc... This is not practical, given the encoding space we haveavailable. We are already matching expected "null FOO reference" trap messageswhen running the spec tests to our own "null reference" messages, so we can dothat for `i31`s as well. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

9ffc9e67 - Cranelift: Remove resumable traps (#8809)

Fri, 14 Jun 2024 19:26:11 +0000

Cranelift: Remove resumable traps (#8809)These were originally a SpiderMonkey-ism and have been unused eversince. It was introduced for GC integration, where the runtime could dosomething to make Cranelift code hit a trap and pause for a GC and then resumeexecution once GC completed. But it is unclear that, as implemented, this isactually a useful mechanism for doing that (compared to, say, loading from someWell Known page and the GC protecting that page and catching signals tointerrupt the mutator, or simply branching and doing a libcall). And if someonehas that particular use case in the future (Wasmtime and its GC integrationdoesn't need exactly this) then we can design something for what is actuallyneeded at that time, instead of carrying this cruft forward forever. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

0fa13013 - Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)

Thu, 04 Apr 2024 00:24:50 +0000

Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)\### The `GcRuntime` and `GcCompiler` TraitsThis commit factors out the details of the garbage collector away from the restof the runtime and the compiler. It does this by introducing two new traits,very similar to a subset of [those proposed in the Wasm GC RFC], although notall equivalent functionality has been added yet because Wasmtime doesn'tsupport, for example, GC structs yet:[those proposed in the Wasm GC RFC]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#defining-the-pluggable-gc-interface1. The `GcRuntime` trait: This trait defines how to create new GC heaps, run collections within them, and execute the various GC barriers the collector requires. Rather than monomorphize all of Wasmtime on this trait, we use it as a dynamic trait object. This does imply some virtual call overhead and missing some inlining (and resulting post-inlining) optimization opportunities. However, it is *much* less disruptive to the existing embedder API, results in a cleaner embedder API anyways, and we don't believe that VM runtime/embedder code is on the hot path for working with the GC at this time anyways (that would be the actual Wasm code, which has inlined GC barriers and direct calls and all of that). In the future, once we have optimized enough of the GC that such code is ever hot, we have options we can investigate at that time to avoid these dynamic virtual calls, like only enabling one single collector at build time and then creating a static type alias like `type TheOneGcImpl = ...;` based on the compile time configuration, and using this type alias in the runtime rather than a dynamic trait object. The `GcRuntime` trait additionally defines a method to reset a GC heap, for use by the pooling allocator. This allows reuse of GC heaps across different stores. This integration is very rudimentary at the moment, and is missing all kinds of configuration knobs that we should have before deploying Wasm GC in production. This commit is large enough as it is already! Ideally, in the future, I'd like to make it so that GC heaps receive their memory region, rather than allocate/reserve it themselves, and let each slot in the pooling allocator's memory pool be *either* a linear memory or a GC heap. This would unask various capacity planning questions such as "what percent of memory capacity should we dedicate to linear memories vs GC heaps?". It also seems like basically all the same configuration knobs we have for linear memories apply equally to GC heaps (see also the "Indexed Heaps" section below).2. The `GcCompiler` trait: This trait defines how to emit CLIF that implements GC barriers for various operations on GC-managed references. The Rust code calls into this trait dynamically via a trait object, but since it is customizing the CLIF that is generated for Wasm code, the Wasm code itself is not making dynamic, indirect calls for GC barriers. The `GcCompiler` implementation can inline the parts of GC barrier that it believes should be inline, and leave out-of-line calls to rare slow paths.All that said, there is still only a single implementation of each of thesetraits: the existing deferred reference-counting (DRC) collector. So there is abunch of code motion in this commit as the DRC collector was further isolatedfrom the rest of the runtime and moved to its own submodule. That said, this wasnot *purely* code motion (see "Indexed Heaps" below) so it is worth not simplyskipping over the DRC collector's code in review.\### Indexed HeapsThis commit does bake in a couple assumptions that must be shared across allcollector implementations, such as a shared `VMGcHeader` that all objectsallocated within a GC heap must begin with, but the most notable andfar-reaching of these assumptions is that all collectors will use "indexedheaps".What we are calling indexed heaps are basically the three following invariants:1. All GC heaps will be a single contiguous region of memory, and all GC objects will be allocated within this region of memory. The collector may ask the system allocator for additional memory, e.g. to maintain its free lists, but GC objects themselves will never be allocated via `malloc`.2. A pointer to a GC-managed object (i.e. a `VMGcRef`) is a 32-bit offset into the GC heap's contiguous region of memory. We never hold raw pointers to GC objects (although, of course, we have to compute them and use them temporarily when actually accessing objects). This means that deref'ing GC pointers is equivalent to deref'ing linear memory pointers: we need to add a base and we also check that the GC pointer/index is within the bounds of the GC heap. Furthermore, compressing 64-bit pointers into 32 bits is a fairly common technique among high-performance GC implementations[^compressed-oops][^v8-ptr-compression] so we are in good company.3. Anything stored inside the GC heap is untrusted. Even each GC reference that is an element of an `(array (ref any))` is untrusted, and bounds checked on access. This means that, for example, we do not store the raw pointer to an `externref`'s host object inside the GC heap. Instead an `externref` now stores an ID that can be used to index into a side table in the store that holds the actual `Box` host object, and accessing that side table is always checked.[^compressed-oops]: See ["Compressed OOPs" in OpenJDK.](https://wiki.openjdk.org/display/HotSpot/CompressedOops)[^v8-ptr-compression]: See [V8's pointer compression](https://v8.dev/blog/pointer-compression).The good news with regards to all the bounds checking that this scheme impliesis that we can use all the same virtual memory tricks that linear memories useto omit explicit bounds checks. Additionally, (2) means that the sizes of GCobjects is that much smaller (and therefore that much more cache friendly)because they are only holding onto 32-bit, rather than 64-bit, references toother GC objects. (We can, in the future, support GC heaps up to 16GiB in sizewithout losing 32-bit GC pointers by taking advantage of `VMGcHeader` alignmentand storing aligned indices rather than byte indices, while still leaving thebottom bit available for tagging as an `i31ref` discriminant. Should we everneed to support even larger GC heap capacities, we could go to full 64-bitreferences, but we would need explicit bounds checks.)The biggest benefit of indexed heaps is that, because we are (explicitly orimplicitly) bounds checking GC heap accesses, and because we are not otherwisetrusting any data from inside the GC heap, we greatly reduce how badly thingscan go wrong in the face of collector bugs and GC heap corruption. We areessentially sandboxing the GC heap region, the same way that linear memory is asandbox. GC bugs could lead to the guest program accessing the wrong GC object,or getting garbage data from within the GC heap. But only garbage data fromwithin the GC heap, never outside it. The worse that could happen would be if wedecided not to zero out GC heaps between reuse across stores (which is a validtrade off to make, since zeroing a GC heap is a defense-in-depth techniquesimilar to zeroing a Wasm stack and not semantically visible in the absence ofGC bugs) and then a GC bug would allow the current Wasm guest to read old GCdata from the old Wasm guest that previously used this GC heap. But again, itcould never access host data.Taken altogether, this allows for collector implementations that are nearly freefrom `unsafe` code, and unsafety can otherwise be targeted and limited in scope,such as interactions with JIT code. Most importantly, we do not have to maintaincritical invariants across the whole system -- invariants which can't be nicelyencapsulated or abstracted -- to preserve memory safety. Such holisticinvariants that refuse encapsulation are otherwise generally a huge safetyproblem with GC implementations.\### `VMGcRef` is *NOT* `Clone` or `Copy` Anymore`VMGcRef` used to be `Clone` and `Copy`. It is not anymore. The motivation herewas to be sure that I was actually calling GC barriers at all the correctplaces. I couldn't be sure before. Now, you can still explicitly copy a raw GCreference without running GC barriers if you need to and understand why that'sokay (aka you are implementing the collector), but that is something you have toopt into explicitly by calling `unchecked_copy`. The default now is that youcan't just copy the reference, and instead call an explicit `clone` method (not*the* `Clone` trait, because we need to pass in the GC heap context to run theGC barriers) and it is hard to forget to do that accidentally. This resulted ina pretty big amount of churn, but I am wayyyyyy more confident that the correctGC barriers are called at the correct times now than I was before.\### `i31ref`I started this commit by trying to add `i31ref` support. And it grew into thewhole traits interface because I found that I needed to abstract GC barriersinto helpers anyways to avoid running them for `i31ref`s, so I figured that Imight as well add the whole traits interface. In comparison, `i31ref` support ismuch easier and smaller than that other part! But it was also difficult to pullapart from this commit, sorry about that!---------------------Overall, I know this is a very large commit. I am super happy to have somesynchronous meetings to walk through this all, give an overview of thearchitecture, answer questions directly, etc... to make review easier!prtest:full List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

9ec02f9d - Decouple `serde` from its `derive` crate (#6917)

Tue, 29 Aug 2023 16:02:06 +0000

Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

92024ad1 - Function references (#5288)

Fri, 26 May 2023 15:26:00 +0000

Function references (#5288)* Make wasmtime-types type check* Make wasmtime-environ type check.* Make wasmtime-runtime type check* Make cranelift-wasm type check* Make wasmtime-cranelift type check* Make wasmtime type check* Make wasmtime-wast type check* Make testsuite compile* Address Luna's comments* Restore compatibility with effect-handlers/wasm-tools#func-ref-2* Add function refs feature flag; support testing* Provide function references support in helpers- Always support Index in blocktypes- Support Index as table type by pretending to be Func- Etc* Implement ref.as_non_null* Add br_on_null* Update Cargo.lock to use wasm-tools with peekThis will ultimately be reverted when we refer towasm-tools#function-references, which doesn't have peek, but does have typeannotations on CallRef* Add call_ref* Support typed function references in ref.null* Implement br_on_non_null* Remove extraneous flag; default func refs false* Use IndirectCallToNull trap code for call_ref* Factor common call_indirect / call_ref into a fn* Remove copypasta clippy attribute / format* Add a some more tests for typed table instructionsThere certainly need to be many more, but this at least catches the bugs fixedin the next commit* Fix missing typed cases for table_grow, table_fill* Document trap code; remove answered question* Mark wasm-tools to wasmtime reftype infallible* Fix reversed conditional* Scope externref/funcref shorthands within WasmRefType* Merge with upstream* Make wasmtime compile again* Fix warnings* Remove Bot from the type algebra* Fix table tests.`wast::Cranelift::spec::function_references::table``wast::Cranelift::spec::function_references::table_pooling`* Fix table{get,set} tests.```wast::Cranelift::misc::function_references::table_getwast::Cranelift::misc::function_references::table_get_poolingwast::Cranelift::misc::function_references::table_setwast::Cranelift::misc::function_references::table_set_pooling```* Insert subtype check to fix local_get tests.```wast::Cranelift::spec::function_references::local_getwast::Cranelift::spec::function_references::local_get_pooling```* Fix compilation of `br_on_non_null`.The branch destinations were the other way round... :-)Fixes the following test failures:```wast::Cranelift::spec::function_references::br_on_non_nullwast::Cranelift::spec::function_references::br_on_non_null_pooling```* Fix ref_as_non_null tests.The test was failing due to the wrong error message being printed. Asper upstream folks' suggest we were using the trap code`IndirectCallToNull`, but it produces an unexpected error message.This commit reinstates the `NullReference` trap code. It produces theexpected error message. We will have to chat with the maintainersupstream about how to handle these "test failures".Fixes the following test failures:```wast::Cranelift::spec::function_references::ref_as_non_nullwast::Cranelift::spec::function_references::ref_as_non_null_pooling```* Fix a call_ref regression.* Fix global tests.Extend `is_matching_assert_invalid_error_message` to circumvent the textual error message failure.Fixes the following test failures:```wast::Cranelift::spec::function_references::globalwast::Cranelift::spec::function_references::global_pooling```* Cargo update* Update* Spell out some cases in match_val* Disgusting hack to subvert limitations of type reconstruction.In the function `wasmtime::values::Val::ty()` attempts to reconstructthe type of its underlying value purely based on the shape of thevalue. With function references proposal this sort of reconstructionis no longer complete as a source reference type may have beennullable. Nullability is not inferrable by looking at the shape of theruntime object alone.Consequently, the runtime cannot reconstruct the type for`Val::FuncRef` and `Val::ExternRef` by looking at their respectiveshapes.* Address workflows comments.* null reference => null_reference for CLIF parsing compliance.* Delete duplicate-loads-dynamic-memory-egraph (again)* Idiomatic code change.* Nullability subtyping + fix non-null storage check.This commit removes the `hacky_eq` check in `func.rs`. Instead it isreplaced by a subtype check. This subtype check occurs in`externals.rs` too.This commit also fixes a bug. Previously, it was possible to store anull reference into a non-null table cell. I have added to new testcases for this bug: one for funcrefs and another for externrefs.* Trigger unimplemented for typed function references. Format values.rs* run cargo fmt* Explicitly match on HeapType::Extern.* Address cranelift-related feedback* Remove PartialEq,Eq from ValType, RefType, HeapType.* Pin wasmparser to a fairly recent commit.* Run cargo fmt* Ignore tail call tests.* Remove garbage* Revert changes to wasmtime public API.* Run cargo fmt* Get more CI passing (#19)* Undo Cargo.lock changes * Fix build of cranelift tests* Implement link-time matches relation. Disable tests failing due to lack of public API support.* Run cargo fmt* Run cargo fmt* Initial implementation of eager table initialization* Tidy up eager table initialisation* Cargo fmt* Ignore type-equivalence test* Replace TODOs with descriptive comments.* Various changes found during review (#21)* Clarify a comment This isn't only used for null references * Resolve a TODO in local init Don't initialize non-nullable locals to null, instead skip initialization entirely and wasm validation will ensure it's always initialized in the scope where it's used. * Clarify a comment and skipping the null check. * Remove a stray comment * Change representation of `WasmHeapType` Use a `SignatureIndex` instead of a `u32` which while not 100% correct should be more correct. This additionally renames the `Index` variant to `TypedFunc` to leave space for future types which aren't functions to not all go into an `Index` variant. This required updates to Winch because `wasmtime_environ` types can no longer be converted back to their `wasmparser` equivalents. Additionally this means that all type translation needs to go through some form of context to resolve indices which is now encapsulated in a `TypeConvert` trait implemented in various locations. * Refactor table initialization Reduce some duplication and simplify some data structures to have a more direct form of table initialization and a bit more graceful handling of element-initialized tables. Additionally element-initialize tables are now treated the same as if there's a large element segment initializing them. * Clean up some unrelated chagnes * Simplify Table bindings slightly * Remove a no-longer-needed TODO * Add a FIXME for `SignatureIndex` in `WasmHeapType` * Add a FIXME for panicking on exposing function-references types * Fix a warning on nightly * Fix tests for winch and cranelift* Cargo fmt* Fix arity mismatch in aarch64/abi---------Co-authored-by: Daniel Hillerström Co-authored-by: Daniel Hillerström Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

65a3af72 - fuzzgen: Statistics framework (#4868)

Tue, 27 Sep 2022 16:04:57 +0000

fuzzgen: Statistics framework (#4868)* cranelift: Add non user trap codes function * cranelift: Add Fuzzgen stats * cranelift: Use `once_cell` and cleanup some stuff * fuzzgen: Remove total_inputs metric * fuzzgen: Filter empty trap codes List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

bde95557 - Add Trap::trap_code (#2309)

Tue, 27 Oct 2020 21:30:45 +0000

Add Trap::trap_code (#2309)* add Trap::trap_code * Add non-exhaustive wasmtime::TrapCode * wasmtime: Better document TrapCode * move and refactor test List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

25e31739 - Implement Wasm Atomics for Cranelift/newBE/aarch64.

Wed, 29 Jul 2020 09:05:39 +0000

Implement Wasm Atomics for Cranelift/newBE/aarch64.The implementation is pretty straightforward. Wasm atomic instructions fallinto 5 groups* atomic read-modify-write* atomic compare-and-swap* atomic loads* atomic stores* fencesand the implementation mirrors that structure, at both the CLIF and AArch64levels.At the CLIF level, there are five new instructions, one for each group. Somecomments about these:* for those that take addresses (all except fences), the address is contained entirely in a single `Value`; there is no offset field as there is with normal loads and stores. Wasm atomics require alignment checks, and removing the offset makes implementation of those checks a bit simpler.* atomic loads and stores get their own instructions, rather than reusing the existing load and store instructions, for two reasons: - per above comment, makes alignment checking simpler - reuse of existing loads and stores would require extension of `MemFlags` to indicate atomicity, which sounds semantically unclean. For example, then *any* instruction carrying `MemFlags` could be marked as atomic, even in cases where it is meaningless or ambiguous.* I tried to specify, in comments, the behaviour of these instructions as tightly as I could. Unfortunately there is no way (per my limited CLIF knowledge) to enforce the constraint that they may only be used on I8, I16, I32 and I64 types, and in particular not on floating point or vector types.The translation from Wasm to CLIF, in `code_translator.rs` is unremarkable.At the AArch64 level, there are also five new instructions, one for eachgroup. All of them except `::Fence` contain multiple real machineinstructions. Atomic r-m-w and atomic c-a-s are emitted as the usualload-linked store-conditional loops, guarded at both ends by memory fences.Atomic loads and stores are emitted as a load preceded by a fence, and a storefollowed by a fence, respectively. The amount of fencing may be overkill, butit reflects exactly what the SM Wasm baseline compiler for AArch64 does.One reason to implement r-m-w and c-a-s as a single insn which is expandedonly at emission time is that we must be very careful what instructions weallow in between the load-linked and store-conditional. In particular, wecannot allow *any* extra memory transactions in there, since -- particularlyon low-end hardware -- that might cause the transaction to fail, hencedeadlocking the generated code. That implies that we can't present the LL/SCloop to the register allocator as its constituent instructions, since it mightinsert spills anywhere. Hence we must present it as a single indivisibleunit, as we do here. It also has the benefit of reducing the total amount ofwork the RA has to do.The only other notable feature of the r-m-w and c-a-s translations intoAArch64 code, is that they both need a scratch register internally. Ratherthan faking one up by claiming, in `get_regs` that it modifies an extrascratch register, and having to have a dummy initialisation of it, these newinstructions (`::LLSC` and `::CAS`) simply use fixed registers in the rangex24-x28. We rely on the RA's ability to coalesce V<-->R copies to make thecost of the resulting extra copies zero or almost zero. x24-x28 are chosen soas to be call-clobbered, hence their use is less likely to interfere with longlive ranges that span calls.One subtlety regarding the use of completely fixed input and output registersis that we must be careful how the surrounding copy from/to of the arg/resultregisters is done. In particular, it is not safe to simply emit copies insome arbitrary order if one of the arg registers is a real reg. For thatreason, the arguments are first moved into virtual regs if they are notalready there, using a new method `::ensure_in_vreg`.Again, we rely on coalescing to turn them into no-ops in the common case.There is also a ridealong fix for the AArch64 lowering case for`Opcode::Trapif | Opcode::Trapff`, which removes a bug in which two trap insnsin a row were generated.In the patch as submitted there are 6 "FIXME JRS" comments, which mark thingswhich I believe to be correct, but for which I would appreciate a secondopinion. Unless otherwise directed, I will remove them for the final commitbut leave the associated code/comments unchanged. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

fb0b9e3a - Change `proc_exit` to unwind the stack rather than exiting the host process. (#1646)

Wed, 13 May 2020 22:59:43 +0000

Change `proc_exit` to unwind the stack rather than exiting the host process. (#1646)* Remove Cranelift's OutOfBounds trap, which is no longer used. * Change proc_exit to unwind instead of exit the host process. This implements the semantics in https://github.com/WebAssembly/WASI/pull/235. Fixes #783. Fixes #993. * Fix exit-status tests on Windows. * Revert the wiggle changes and re-introduce the wasi-common implementations. * Move `wasi_proc_exit` into the wasmtime-wasi crate. * Revert the spec_testsuite change. * Remove the old proc_exit implementations. * Make `TrapReason` an implementation detail. * Allow exit status 2 on Windows too. * Fix a documentation link. * Really fix a documentation link. List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

10e226f9 - Always use extern crate std in cranelift-codegen

Sat, 28 Sep 2019 13:52:23 +0000

Always use extern crate std in cranelift-codegen List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

1431ab52 - Derive serde traits for TrapCode

Tue, 24 Sep 2019 16:28:40 +0000

Derive serde traits for TrapCode List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs

747ad3c4 - moved crates in lib/ to src/, renamed crates, modified some files' text (#660)

Mon, 28 Jan 2019 23:56:54 +0000

moved crates in lib/ to src/, renamed crates, modified some files' text (#660)moved crates in lib/ to src/, renamed crates, modified some files' text (#660) List of files: /wasmtime-44.0.1/cranelift/codegen/src/ir/trapcode.rs