* Cranellift: remove Baldrdash support and related features.
As noted in Mozilla's bugzilla bug 1781425 [1], the SpiderMonkey team
has recently determined that their current form of integration with
Cranelift is too hard to maintain, and they have chosen to remove it
from their codebase. If and when they decide to build updated support
for Cranelift, they will adopt different approaches to several details
of the integration.
In the meantime, after discussion with the SpiderMonkey folks, they
agree that it makes sense to remove the bits of Cranelift that exist
to support the integration ("Baldrdash"), as they will not need
them. Many of these bits are difficult-to-maintain special cases that
are not actually tested in Cranelift proper: for example, the
Baldrdash integration required Cranelift to emit function bodies
without prologues/epilogues, and instead communicate very precise
information about the expected frame size and layout, then stitched
together something post-facto. This was brittle and caused a lot of
incidental complexity ("fallthrough returns", the resulting special
logic in block-ordering); this is just one example. As another
example, one particular Baldrdash ABI variant processed stack args in
reverse order, so our ABI code had to support both traversal
orders. We had a number of other Baldrdash-specific settings as well
that did various special things.
This PR removes Baldrdash ABI support, the `fallthrough_return`
instruction, and pulls some threads to remove now-unused bits as a
result of those two, with the understanding that the SpiderMonkey folks
will build new functionality as needed in the future and we can perhaps
find cleaner abstractions to make it all work.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1781425
* Review feedback.
* Fix (?) DWARF debug tests: add `--disable-cache` to wasmtime invocations.
The debugger tests invoke `wasmtime` from within each test case under
the control of a debugger (gdb or lldb). Some of these tests started to
inexplicably fail in CI with unrelated changes, and the failures were
only inconsistently reproducible locally. It seems to be cache related:
if we disable cached compilation on the nested `wasmtime` invocations,
the tests consistently pass.
* Review feedback.
Our README was starting to show its age; it did not reflect the current
status of Cranelift well with respect to production maturity, current
supported backends, or performance. This PR makes a pass over the
"Status" section to fix that. It also removes some old/out-of-date
details, like `no_std` support (which has bitrotted).
This patch updates or removes all references to the Cranelift repository. It affects links in README documents, issues that were transferred to the Wasmtime repository, CI badges, and a small bunch of sundry items.
Update the documentation for the merger, and also for various changes in
Cranelift. Remove some old obsolete documentation, and convert the remaining
Sphinx files to Markdown. Some of the remaining content is still out of
date, but this is a step forward.
Enables automated fuzzing on Fuzzit. Runs fuzz regression tests
every push and PR. Runs full fuzzing every push. Fuzzit emails
if it finds crashes.
Uses the existing fuzz targets:
* translate-module - Fuzz valid WebAssembly modules.
* reader-parse - Fuzz IR text format parsing.
Enables automated fuzzing on Fuzzit. Runs fuzz regression tests
every push and PR. Runs full fuzzing every push. Fuzzit emails
if it finds crashes.
Uses the existing fuzz targets:
* translate-module - Fuzz valid WebAssembly modules.
* reader-parse - Fuzz IR text format parsing.
Rust 1.34 gets errors like this:
```
$ cargo +1.34.0 build --release
Compiling cranelift-wasm v0.32.0 (cranelift/cranelift-wasm)
error[E0259]: the name `std` is defined multiple times
|
= note: `std` must be defined only once in the type namespace of this module
error: aborting due to previous error
For more information about this error, try `rustc --explain E0259`.
error: Could not compile `cranelift-wasm`.
To learn more, run the command again with --verbose.
```
Updating to Rust 1.35 fixes this.
With Rust 2018 Edition, the `mod std` trick to alias `core` names to
`std` no longer works, so switch to just having the code use `core`
explicitly.
So instead, switch to just using `core::*` for things that in core.
This is more consistent with other Rust no_std code. And it allows
us to enable `no_std` mode unconditionally in the crates that support
it, which makes testing a little easier.
There actually three cases:
- For things in std and also in core, like `cmp`: Just use them via
`core::*`.
- For things in std and also in alloc, like `Vec`: Import alloc as std, as
use them from std. This allows them to work on both stable (which
doesn't provide alloc, but we don't support no_std mode anyway) and
nightly.
- For HashMap and similar which are not in core or alloc, import them in
the top-level lib.rs files from either std or the third-party hashmap_core
crate, and then have the code use super::hashmap_core.
Also, no_std support continues to be "best effort" at this time and not
something most people need to be testing.
* initial cargo fix run
* Upgrade cranelift-entity crate
* Upgrade bforest crate
* Upgrade the codegen crate
* Upgrade the faerie crate
* Upgrade the filetests crate
* Upgrade the codegen-meta crate
* Upgrade the frontend crate
* Upgrade the cranelift-module crate
* Upgrade the cranelift-native crate
* Upgrade the cranelift-preopt crate
* Upgrade the cranelift-reader crate
* Upgrade the cranelift-serde crate
* Upgrade the cranelift-simplejit crate
* Upgrade the cranelift or cranelift-umbrella crate
* Upgrade the cranelift-wasm crate
* Upgrade cranelift-tools crate
* Use new import style on remaining files
* run format-all.sh
* run test-all.sh, update Readme and travis ci configuration
fixed an AssertionError also
* Remove deprecated functions
We no longer need the Ubuntu LTS restriction, so now the only only
constraint I'm aware of is Firefox's policy. Fortunately, that tracks
the latest stable delayed by only two weeks. So this puts is at
Rust 1.29 now.
Callstack recursion has the property that the maximum stack depth can
grow significantly, depending on the input program. Cranelift uses
several recursive algorithms, however it uses explicit heap-based
stacks to do so.
* Add a comment to .rustfmt.toml explaning why it's here.
* Use `<details>` for specialized information in README.md.
* Describe a more elaborate issue-labelling system.
