Nicholas Nethercote
36c9d23902
`std::hash::Hash` looks like this:
```
pub trait Hash {
fn hash<H>(&self, state: &mut H)
where H: Hasher;
...
}
```
The method is generic.
In contrast, `HashStable` looks like this:
```
pub trait HashStable<Hcx> {
fn hash_stable(&self, hcx: &mut Hcx, hasher: &mut StableHasher);
}
```
and impls look like this (in crates upstream of `rustc_middle`):
```
impl<Hcx: HashStableContext> HashStable<Hcx> for Path {
fn hash_stable(&self, hcx: &mut Hcx, hasher: &mut StableHasher) {
...
}
}
```
or this (in `rustc_middle` and crates downstream of `rustc_middle`):
```
impl<'tcx> HashStable<StableHashingContext<'tcx>> for rustc_feature::Features {
fn hash_stable(&self, hcx: &mut StableHashingContext<'tcx>, hasher: &mut StableHasher) {
...
}
}
```
Differences to `std::hash::Hash`:
- The trait is generic, rather than the method.
- The way impls are written depends their position in the crate graph.
- This explains why we have both `derive(HashStable)` and
`derive(HashStable_Generic)`. The former is for the
downstream-of-`rustc_middle` case, the latter is for the upstream of
`rustc_middle` case.
Why the differences? It all boils down to `HashStable` and
`HashStableContext` being in different crates. But the previous commit
fixed that, which means `HashStable` can be simplified to this, with a
generic method:
```
pub trait HashStable {
fn hash_stable<Hcx: HashStableContext>(&self, hcx: &mut Hcx, hasher: &mut StableHasher);
}
```
and all impls look like this:
```
impl HashStable for Path {
fn hash_stable<Hcx: HashStableContext>(&self, hcx: &mut Hcx, hasher: &mut StableHasher) {
...
}
}
```
Other consequences:
- `derive(HashStable_Generic)` is no longer needed; `derive(HashStable)`
can be used instead.
- In this commit, `derive(HashStable_Generic` is made a synonym of
`derive(HashStable)`. The next commit will remove this synonym,
because it's a change that touches many lines.
- `#[stable_hash_generic]` is no longer needed (for `newtype_index`);
`#[stable_hash]` can be used instead.
- `#[stable_hash_no_context]` was already a synonym of
`#[stable_hash_generic]`, so it's also removed in favour of just
`#[stable_hash]`.
- The difference between `derive(HashStable)` and
`derive(HashStable_NoContext)` now comes down to the difference
between `synstructure::AddBounds::Generics` and
`synstructure::AddBounds::Fields`, which is basically "vanilla derive"
vs "(near) perfect derive".
- I have improved the comments on `HashStableMode` to better
explaining this subtle difference.
- `rustc_middle/src/ich/impls_syntax.rs` is no longer needed; the
relevant impls can be defined in the crate that defines the relevant
type.
- Occurrences of `for<'a> HashStable<StableHashingContext<'a>>` are
replaced with with `HashStable`, hooray.
- The commit adds a `HashStableContext::hashing_controls` method, which
is no big deal. (It's necessary for `AdtDefData::hash_stable`, which
calls `hashing_controls` and used to have an `hcx` that was a
concrete `StableHashingContext` but now has an `hcx` that is just
`Hcx: HashStableContext`.)
Overall this is a big simplification, removing a lot of confusing
complexity in stable hashing traits.
Cranelift codegen backend for rust
The goal of this project is to create an alternative codegen backend for the rust compiler based on Cranelift. This has the potential to improve compilation times in debug mode. If your project doesn't use any of the things listed under "Not yet supported", it should work fine. If not please open an issue.
Download using Rustup
The Cranelift codegen backend is distributed in nightly builds on Linux, macOS and x86_64 Windows. If you want to install it using Rustup, you can do that by running:
rustup component add rustc-codegen-cranelift-preview --toolchain nightly
Once it is installed, you can enable it with one of the following approaches:
CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift cargo +nightly build -Zcodegen-backend- Add the following to
.cargo/config.toml:[unstable] codegen-backend = true [profile.dev] codegen-backend = "cranelift" - Add the following to
Cargo.toml:# This line needs to come before anything else in Cargo.toml cargo-features = ["codegen-backend"] [profile.dev] codegen-backend = "cranelift"
Precompiled builds
You can also download a pre-built version from the releases page.
Extract the dist directory in the archive anywhere you want.
If you want to use cargo clif build instead of having to specify the full path to the cargo-clif executable, you can add the bin subdirectory of the extracted dist directory to your PATH.
(tutorial for Windows, and for Linux/MacOS).
Building and testing
If you want to build the backend manually, you can download it from GitHub and build it yourself:
git clone https://github.com/rust-lang/rustc_codegen_cranelift
cd rustc_codegen_cranelift
./y.sh build
To run the test suite replace the last command with:
./y.sh prepare # only needs to be run the first time
./test.sh
For more docs on how to build and test see build_system/usage.txt or the help message of ./y.sh.
Platform support
| OS \ architecture | x86_64 | AArch64 | Riscv64 | s390x (System-Z) |
|---|---|---|---|---|
| Linux | ✅ | ✅ | ✅1 | ✅1 |
| FreeBSD | ✅1 2 | ❓ | ❓ | ❓ |
| AIX | ❌3 | N/A | N/A | ❌3 |
| Other unixes | ❓ | ❓ | ❓ | ❓ |
| macOS | ✅ | ✅ | N/A | N/A |
| Windows | ✅ | ❌ | N/A | N/A |
✅: Fully supported and tested ❓: Maybe supported, not tested ❌: Not supported at all
Not all targets are available as rustup component for nightly. See notes in the platform support matrix.
Usage
rustc_codegen_cranelift can be used as a near-drop-in replacement for cargo build or cargo run for existing projects.
Assuming $cg_clif_dir is the directory you cloned this repo into and you followed the instructions (y.sh prepare and y.sh build or test.sh).
In the directory with your project (where you can do the usual cargo build), run:
$cg_clif_dir/dist/cargo-clif build
This will build your project with rustc_codegen_cranelift instead of the usual LLVM backend.
For additional ways to use rustc_codegen_cranelift like the JIT mode see usage.md.
Building and testing with changes in rustc code
See rustc_testing.md.
Not yet supported
- SIMD (tracked here,
std::simdfully works,std::archis partially supported) - Unwinding on panics (experimental and not supported on Windows and macOS,
-Cpanic=abortis enabled by default)
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be dual licensed as above, without any additional terms or conditions.
-
Not available as rustup component for nightly. You can build it yourself. ↩︎
-
FreeBSD requires setting
LD_STATIC_TLS_EXTRA=4096to build cg_clif. In addition you need at least FreeBSD 14. ↩︎ -
XCOFF object file format is not supported. ↩︎