e1ff91f439
Fix `--remap-path-prefix` not correctly remapping `rust-src` component paths and unify handling of path mapping with virtualized paths This PR fixes #73167 ("Binaries end up containing path to the rust-src component despite `--remap-path-prefix`") by preventing real local filesystem paths from reaching compilation output if the path is supposed to be remapped. `RealFileName::Named` introduced in #72767 is now renamed as `LocalPath`, because this variant wraps a (most likely) valid local filesystem path. `RealFileName::Devirtualized` is renamed as `Remapped` to be used for remapped path from a real path via `--remap-path-prefix` argument, as well as real path inferred from a virtualized (during compiler bootstrapping) `/rustc/...` path. The `local_path` field is now an `Option<PathBuf>`, as it will be set to `None` before serialisation, so it never reaches any build output. Attempting to serialise a non-`None` `local_path` will cause an assertion faliure. When a path is remapped, a `RealFileName::Remapped` variant is created. The original path is preserved in `local_path` field and the remapped path is saved in `virtual_name` field. Previously, the `local_path` is directly modified which goes against its purpose of "suitable for reading from the file system on the local host". `rustc_span::SourceFile`'s fields `unmapped_path` (introduced by #44940) and `name_was_remapped` (introduced by #41508 when `--remap-path-prefix` feature originally added) are removed, as these two pieces of information can be inferred from the `name` field: if it's anything other than a `FileName::Real(_)`, or if it is a `FileName::Real(RealFileName::LocalPath(_))`, then clearly `name_was_remapped` would've been false and `unmapped_path` would've been `None`. If it is a `FileName::Real(RealFileName::Remapped{local_path, virtual_name})`, then `name_was_remapped` would've been true and `unmapped_path` would've been `Some(local_path)`. cc `@eddyb` who implemented `/rustc/...` path devirtualisation |
||
---|---|---|
.. | ||
.github/workflows | ||
.vscode | ||
build_sysroot | ||
crate_patches | ||
docs | ||
example | ||
patches | ||
scripts | ||
src | ||
.cirrus.yml | ||
.gitattributes | ||
.gitignore | ||
build.sh | ||
Cargo.lock | ||
Cargo.toml | ||
clean_all.sh | ||
LICENSE-APACHE | ||
LICENSE-MIT | ||
prepare.sh | ||
Readme.md | ||
rust-toolchain | ||
rustfmt.toml | ||
test.sh |
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.
Building and testing
$ git clone https://github.com/bjorn3/rustc_codegen_cranelift.git
$ cd rustc_codegen_cranelift
$ ./prepare.sh # download and patch sysroot src and install hyperfine for benchmarking
$ ./build.sh
To run the test suite replace the last command with:
$ ./test.sh
This will implicitly build cg_clif too. Both build.sh
and test.sh
accept a --debug
argument to
build in debug mode.
Alternatively you can download a pre built version from GHA. It is listed in the artifacts section of workflow runs. Unfortunately due to GHA restrictions you need to be logged in to access it.
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 (prepare.sh
and build.sh
or test.sh
).
In the directory with your project (where you can do the usual cargo build
), run:
$ $cg_clif_dir/build/cargo.sh 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.
Configuration
See the documentation on the BackendConfig
struct in config.rs for all
configuration options.
Not yet supported
- Inline assembly (no cranelift support)
- On Linux there is support for invoking an external assembler for
global_asm!
andasm!
.llvm_asm!
will remain unimplemented forever.asm!
doesn't yet support reg classes. You have to specify specific registers instead.
- On Linux there is support for invoking an external assembler for
- SIMD (tracked here, some basic things work)
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.