rust/config.example.toml, branch 1.78.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.78.02024-03-11T19:17:00+00:00[bootstrap] Move the split-debuginfo setting to the per-target section2024-03-11T19:17:00+00:00Tim Neumanntimnn@google.com2024-02-28T19:13:43+00:00urn:sha1:0e354c98a82df53df04e49c5d0f7107c03482d42Bootstrap: Add argument for building llvm bitcode linker2024-03-11T12:35:55+00:00Kjetil Kjekakjetil@muybridge.com2024-02-06T19:09:55+00:00urn:sha1:6a50d059a594f35d70af30a33a4b395616663f68Add `target.*.runner` configuration for targets2024-03-08T15:44:03+00:00Alex Crichtonalex@alexcrichton.com2024-03-06T20:10:52+00:00urn:sha1:dd95cb7106e60a79a994899aa4836d6dc8b5b9fa
This commit adds a `runner` field configuration to `config.toml` for
specifying a wrapper executable when executing binaries for a target.
This is pulled out of #122036 where a WebAssembly runtime is used, for
example, to execute tests for `wasm32-wasip1`.
The name "runner" here is chosen to match Cargo's `CARGO_*_RUNNER`
configuration, and to make things a bit more consistent this
additionally renames compiletest's `--runtool` argument to `--runner`.
Rollup merge of #121976 - lu-zero:bootstrap-cache, r=onur-ozkan2024-03-06T21:41:53+00:00Matthias Krügermatthias.krueger@famsik.de2024-03-06T21:41:53+00:00urn:sha1:24a2169a23dd3c521c229044db9f748189f30c58
Add an option to have an external download/bootstrap cache
Follow up from #116697 to address https://github.com/rust-lang/rust/pull/116697#pullrequestreview-1677176395
Add a build option to specify the bootstrap cache2024-03-05T09:35:43+00:00Luca Barbatolu_zero@gentoo.org2024-03-04T10:06:24+00:00urn:sha1:c98e25bab9503741bcafd20f79a230348d6b7884
Setting the bootstrap cache path to an external location can help to
speed up builds in cases where the build directory is not kept between
builds, e.g. in CI or other automated build systems.
Add a new `wasm32-wasip1` target to rustc2024-03-02T17:03:51+00:00Alex Crichtonalex@alexcrichton.com2024-01-29T16:19:42+00:00urn:sha1:cb39d6c5159b516a1bf3652a62527a7a69037676
This commit adds a new target called `wasm32-wasip1` to rustc.
This new target is explained in these two MCPs:
* https://github.com/rust-lang/compiler-team/issues/607
* https://github.com/rust-lang/compiler-team/issues/695
In short, the previous `wasm32-wasi` target is going to be renamed to
`wasm32-wasip1` to better live alongside the [new
`wasm32-wasip2` target](https://github.com/rust-lang/rust/pull/119616).
This new target is added alongside the `wasm32-wasi` target and has the
exact same definition as the previous target. This PR is effectively a
rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that
as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi`
target is not being removed at this time. This change will reach stable
Rust before even a warning about the rename will be printed. At this
time this change is just the start where a new target is introduced and
users can start migrating if they support only Nightly for example.
Add `rust.frame-pointers` config option2024-02-18T21:23:09+00:00Nilstrieb48135649+Nilstrieb@users.noreply.github.com2024-02-16T21:11:19+00:00urn:sha1:09e60434830d4b6387df03ee54cfb5207a06a1ff
This is very helpful for profiling. I've hacked this in many times, so
let's add it properly.
remove extraneous text from example config2024-02-18T08:41:31+00:00Tshepang Mbambotshepang@gmail.com2024-02-18T08:41:31+00:00urn:sha1:61479730826b83c92285d60b8571b8f5ce428129Support configuring the set of codegen backends to build per host triple2024-01-25T18:55:27+00:00bjorn317426603+bjorn3@users.noreply.github.com2023-06-08T21:22:23+00:00urn:sha1:28af00c611164bfbb242b2184bd3168ac1e57d2b
This allows building the compiler itself with one backend while using
another backend at runtime. For example this allows compiling rustc to
wasm using LLVM, while using Cranelift at runtime to produce actual
code. Cranelift can't compile to wasm, but is perfectly capable of
running on wasm. LLVM can compile to wasm, but can't run on wasm. [^1]
[^1]: The prototype of this still requires a couple of other patches.
add a new `optimized_compiler_builtins` option2024-01-07T10:04:40+00:00jyngithub@jyn.dev2023-12-25T12:46:12+00:00urn:sha1:6a409ddbe40f55dd5f89442d24548b42b0822f60
in particular, this makes the `c` feature for compiler-builtins an explicit opt-in, rather than silently detected by whether `llvm-project` is checked out on disk.
exposing this is necessary because the `cc` crate doesn't support cross-compiling to MSVC, and we want people to be able to run `x check --target foo` regardless of whether they have a c toolchain available.
this also uses the new option in CI, where we *do* want to optimize compiler_builtins.
the new option is off by default for the `dev` channel and on otherwise.