rust/compiler/rustc_codegen_cranelift
bors b71fb5edc0 Auto merge of #132460 - lcnr:questionable-uwu, r=compiler-errors
Use `TypingMode` throughout the compiler instead of `ParamEnv`

Hopefully the biggest single PR as part of https://github.com/rust-lang/types-team/issues/128.

## `infcx.typing_env` while defining opaque types

I don't know how'll be able to correctly handle opaque types when using something taking a `TypingEnv` while defining opaque types. To correctly handle the opaques we need to be able to pass in the current `opaque_type_storage` and return constraints, i.e. we need to use a proper canonical query. We should migrate all the queries used during HIR typeck and borrowck where this matters to proper canonical queries. This is

## `layout_of` and `Reveal::All`

We convert the `ParamEnv` to `Reveal::All` right at the start of the `layout_of` query, so I've changed callers of `layout_of` to already use a post analysis `TypingEnv` when encountering it.

ca87b535a0/compiler/rustc_ty_utils/src/layout.rs (L51)

## `Ty::is_[unpin|sized|whatever]`

I haven't migrated `fn is_item_raw` to use `TypingEnv`, will do so in a followup PR, this should significantly reduce the amount of `typing_env.param_env`. At some point there will probably be zero such uses as using the type system while ignoring the `typing_mode` is incorrect.

## `MirPhase` and phase-transitions

When inside of a MIR-body, we can mostly use its `MirPhase` to figure out the right `typing_mode`. This does not work during phase transitions, most notably when transitioning from `Analysis` to `Runtime`:

dae7ac133b/compiler/rustc_mir_transform/src/lib.rs (L606-L625)

All these passes still run with `MirPhase::Analysis`, but we should only use `Reveal::All` once we're run the `RevealAll` pass. This required me to manually construct the right `TypingEnv` in all these passes. Given that it feels somewhat easy to accidentally miss this going forward, I would maybe like to change `Body::phase` to an `Option` and replace it at the start of phase transitions. This then makes it clear that the MIR is currently in a weird state.

r? `@ghost`
2024-11-18 21:07:05 +00:00
..
.github Merge commit '6d35b4c9a04580366fd800692a5b5db79d766530' into sync_cg_clif-2024-09-22 2024-09-23 11:20:46 +00:00
.vscode
.zed Merge commit '69b3f5a426a5c1c05236a45b36f6679d95fbe01b' into sync_cg_clif-2024-08-09 2024-08-09 17:18:46 +00:00
build_system Merge commit '5b1246bb4bed72fd0bb8fa497d8e5ed2c7f3515c' into sync_cg_clif-2024-11-02 2024-11-02 14:53:30 +00:00
docs Merge commit 'fbda869b4e230c788b6bce426038ba8419956f2d' into sync_cg_clif-2024-04-05 2024-04-05 16:20:23 +00:00
example remove support for rustc_safe_intrinsic attribute; use rustc_intrinsic functions instead 2024-11-08 09:16:00 +01:00
patches Merge commit '1fa693ca4462fc1f790693464cf765ad693616af' into sync_cg_clif-2024-11-09 2024-11-09 13:48:06 +00:00
scripts Merge commit '1fa693ca4462fc1f790693464cf765ad693616af' into sync_cg_clif-2024-11-09 2024-11-09 13:48:06 +00:00
src Auto merge of #132460 - lcnr:questionable-uwu, r=compiler-errors 2024-11-18 21:07:05 +00:00
.cirrus.yml Merge commit '6d35b4c9a04580366fd800692a5b5db79d766530' into sync_cg_clif-2024-09-22 2024-09-23 11:20:46 +00:00
.gitattributes
.gitignore Merge commit '3270432f4b0583104c8b9b6f695bf97d6bbf3ac2' into sync_cg_clif-2024-05-13 2024-05-13 13:26:33 +00:00
Cargo.lock Merge commit '5b1246bb4bed72fd0bb8fa497d8e5ed2c7f3515c' into sync_cg_clif-2024-11-02 2024-11-02 14:53:30 +00:00
Cargo.toml Merge commit '5b1246bb4bed72fd0bb8fa497d8e5ed2c7f3515c' into sync_cg_clif-2024-11-02 2024-11-02 14:53:30 +00:00
clean_all.sh Merge commit '6d35b4c9a04580366fd800692a5b5db79d766530' into sync_cg_clif-2024-09-22 2024-09-23 11:20:46 +00:00
config.txt Merge commit '69b3f5a426a5c1c05236a45b36f6679d95fbe01b' into sync_cg_clif-2024-08-09 2024-08-09 17:18:46 +00:00
LICENSE-APACHE
LICENSE-MIT
Readme.md Distribute rustc_codegen_cranelift for Windows 2024-08-10 21:16:44 +00:00
rust-toolchain Merge commit '1fa693ca4462fc1f790693464cf765ad693616af' into sync_cg_clif-2024-11-09 2024-11-09 13:48:06 +00:00
rustfmt.toml Update use declarations formatting options. 2024-07-29 08:26:08 +10:00
test.sh Merge commit '6d35b4c9a04580366fd800692a5b5db79d766530' into sync_cg_clif-2024-09-22 2024-09-23 11:20:46 +00:00
y.cmd Merge commit '3270432f4b0583104c8b9b6f695bf97d6bbf3ac2' into sync_cg_clif-2024-05-13 2024-05-13 13:26:33 +00:00
y.ps1 Merge commit '3270432f4b0583104c8b9b6f695bf97d6bbf3ac2' into sync_cg_clif-2024-05-13 2024-05-13 13:26:33 +00:00
y.sh Merge commit '6d35b4c9a04580366fd800692a5b5db79d766530' into sync_cg_clif-2024-09-22 2024-09-23 11:20:46 +00:00

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 and x86_64 macOS. 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 prepare
$ ./y.sh build

To run the test suite replace the last command with:

$ ./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
AIX 2 N/A N/A 2
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

License

Licensed under either of

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.


  1. Not available as rustup component for nightly. You can build it yourself. ↩︎

  2. XCOFF object file format is not supported. ↩︎