| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix the dead link in the bootstrap README
This link has been changed since https://github.com/rust-lang/rustc-dev-guide/pull/1939
|
|
Run rustfmt on files that need it.
Somehow these files aren't properly formatted. By default `x fmt` and `x tidy` only check files that have changed against master, so if an ill-formatted file somehow slips in it can stay that way as long as it doesn't get modified(?)
I found these when I ran `x fmt` explicitly on every `.rs` file in the repo, while working on
https://github.com/rust-lang/compiler-team/issues/750.
|
|
|
|
Somehow these files aren't properly formatted. By default `x fmt` and `x
tidy` only check files that have changed against master, so if an
ill-formatted file somehow slips in it can stay that way as long as it
doesn't get modified(?)
I found these when I ran `x fmt` explicitly on every `.rs` file in the
repo, while working on
https://github.com/rust-lang/compiler-team/issues/750.
|
|
|
|
|
|
Fix `unexpected_cfgs` lint on std
closes #125291
r? rust-lang/compiler
|
|
|
|
|
|
|
|
refactor: add rustc-perf submodule to src/tools
Currently, it's very challenging to perform a sandboxed `opt-dist`
bootstrap because the tool requires `rustc-perf` to be present, but
there is no proper management/tracking of it. Instead, a specific commit
is hardcoded where it is needed, and a non-checksummed zip is fetched
ad-hoc. This happens in two places:
`src/ci/docker/host-x86_64/dist-x86_64-linux/Dockerfile`:
```dockerfile
ENV PERF_COMMIT 4f313add609f43e928e98132358e8426ed3969ae
RUN curl -LS -o perf.zip https://ci-mirrors.rust-lang.org/rustc/rustc-perf-$PERF_COMMIT.zip && \
unzip perf.zip && \
mv rustc-perf-$PERF_COMMIT rustc-perf && \
rm perf.zip
```
`src/tools/opt-dist/src/main.rs`
```rust
// FIXME: add some mechanism for synchronization of this commit SHA with
// Linux (which builds rustc-perf in a Dockerfile)
// rustc-perf version from 2023-10-22
const PERF_COMMIT: &str = "4f313add609f43e928e98132358e8426ed3969ae";
let url = format!("https://ci-mirrors.rust-lang.org/rustc/rustc-perf-{PERF_COMMIT}.zip");
let client = reqwest::blocking::Client::builder()
.timeout(Duration::from_secs(60 * 2))
.connect_timeout(Duration::from_secs(60 * 2))
.build()?;
let response = retry_action(
|| Ok(client.get(&url).send()?.error_for_status()?.bytes()?.to_vec()),
"Download rustc-perf archive",
5,
)?;
```
This causes a few issues:
1. Maintainers need to be careful to bump PERF_COMMIT in both places
every time
2. In order to run `opt-dist` in a sandbox, you need to provide your own
`rustc-perf` (https://github.com/rust-lang/rust/pull/125125), but to
figure out which commit to provide you need to grep the Dockerfile
3. Even if you manage to provide the correct `rustc-perf`, its
dependencies are not included in the `vendor/` dir created during
`dist`, so it will fail to build from the published source tarballs
4. It is hard to provide any level of automation around updating the
`rustc-perf` in use, leading to staleness
Fundamentally, this means `rustc-src` tarballs no longer contain
everything you need to bootstrap Rust, and packagers hoping to leverage
`opt-dist` need to go out of their way to keep track of this "hidden"
dependency on `rustc-perf`.
This change adds rustc-perf as a git submodule, pinned to the current
`PERF_COMMIT` 4f313add609f43e928e98132358e8426ed3969ae. Subsequent
commits ensure the submodule is initialized when necessary, and make use
of it in `opt-dist`.
|
|
keith:ks/remove-unnecessary-fembed-bitcode-usage-now-that-it-s-deprecated, r=clubby789
Remove unnecessary -fembed-bitcode usage now that it's deprecated
This is a partial revert of 6d819a4b8f45b170e7c2c415df20cfa2e0cbbf7f because https://github.com/rust-lang/cc-rs/pull/812 removed this flag entirely, meaning we shouldn't have to pass this manually anymore
|
|
opt-dist
|
|
|
|
This avoids having normal builds pay the cost of initializing that
submodule, while still ensuring it's available whenever `opt-dist` is
built.
Note that, at this point, `opt-dist` will not yet use the submodule,
that will be handled in a subsequent commit.
|
|
Update libc to 0.2.155
Motivation: To fix `-Zbuild-std` / Xargo for visionOS targets.
EDIT: Blocked on ~https://github.com/rust-lang/libc/issues/3608 / https://github.com/rust-lang/libc/pull/3609~ ~https://github.com/rust-lang/libc/pull/3682 and https://github.com/rust-lang/libc/pull/3690~ No longer blocked.
|
|
keep the `STAGE0_MISSING_TARGETS` list updated
Implements https://github.com/rust-lang/rust/pull/124461#issuecomment-2092574309.
r? pietroalbini
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
set `rust.channel` properly in source tarballs
This change sets the appropriate channel by default when using nightly, beta or stable source tarballs.
Fixes #124618
|
|
the default value changes on `x86_64-unknown-linux-gnu`, and semantics kinda
as it will impact the target's default linker
|
|
`x86_64-unknown-linux-gnu` has switched to using the self-contained linker
by default (unless asked not to), so we have to build rust-lld:
- when we build our own llvm
- when we use download-ci-llvm
- otherwise, when using an external llvm we can't enable it
|
|
This is used to notify we want to use rust-lld as the default linker in
a target.
|
|
This change sets the appropriate channel by default when using nightly,
beta or stable source tarballs.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
This profile has only undergone minimal tweaks since it was originally
drafted. I asked a number of compiler contributors and they said they
set rust.debug explicitly. This was even true for one contributor that
set `rust.debug` = false! Almost everyone seems slightly surprised that
`rust.debug = true` is not the default.
However, adding full debuginfo at this level costs multiple gigabytes!
We can still get much better debuginfo by setting "line-tables-only"
at the cost of only 150~200 MB.
|
|
In case the source is not in the same filesystem.
|
|
use key-value format in stage0 file
Currently, we are working on the python removal task on bootstrap. Which means we have to extract some data from the stage0 file using shell scripts. However, parsing values from the stage0.json file is painful because shell scripts don't have a built-in way to parse json files.
This change simplifies the stage0 file format to key-value pairs, which makes it easily readable from any environment.
See the zulip thread for more details: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Using.20different.20format.20in.20the.20stage0.20file
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
check if `x test tests` missing any test directory
Add a unit test to ensure we don't skip any test directories for `x test tests` in the future.
|
|
bootstrap: add comments for the automatic dry run
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Display walltime benchmarks with subnanosecond precision
With modern CPUs running at more than one cycle per nanosecond the current precision is insufficient to resolve differences worth several cycles per iteration.
Granted, walltime benchmarks often are noisy but occasionally, especially when no allocations are involved, the difference really is just a few cycles.
example results when benchmarking 1-4 serialized ADD instructions and an empty bench body
```
running 4 tests
test add ... bench: 0.24 ns/iter (+/- 0.00)
test add2 ... bench: 0.48 ns/iter (+/- 0.01)
test add3 ... bench: 0.72 ns/iter (+/- 0.01)
test add4 ... bench: 0.96 ns/iter (+/- 0.01)
test empty ... bench: 0.24 ns/iter (+/- 0.00)
```
|
|
Co-authored-by: jyn <github@jyn.dev>
|
|
Upgrade pre-built Clang used in MSVC and MacOS builds, move MSVC builds to Server 2022
Fixes #92948
Example working MacOS and Windows builds: <https://github.com/rust-lang/rust/actions/runs/8989360201>
There is a [bug in Clang 18](https://github.com/llvm/llvm-project/pull/81849) that causes issues when building for Arm64 in later parts of the build (specifically `libgit2`). As a workaround, we will still use the pre-built Clang to build LLVM but will use MSVC for the rest of the Arm64 build.
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Ignore empty RUSTC_WRAPPER in bootstrap
This change ignores the RUSTC_WRAPPER_REAL environment variable if it's set to the empty string. This matches cargo behaviour and allows users to easily shadow a globally set RUSTC_WRAPPER (which they might have set for non-rustc projects).
I hit this because I have RUSTC_WRAPPER set to `sccache` in my fish universal env vars, and I can only shadow those locally with an empty string, I can't unset it entirely.
|
|
This change ignores the RUSTC_WRAPPER_REAL environment variable if it's
set to the empty string. This matches cargo behaviour and allows users
to easily shadow a globally set RUSTC_WRAPPER (which they might have set
for non-rustc projects).
|
|
|
|
This is a partial revert of 6d819a4b8f45b170e7c2c415df20cfa2e0cbbf7f
because https://github.com/rust-lang/cc-rs/pull/812 removed this flag
entirely, meaning we shouldn't have to pass this manually anymore
|
|
Reason:
In order to build the Windows version of the Rust toolchain for the Android platform, the following patch to the cc is crate is required to avoid incorrectly determining that we are building with the Android NDK: https://github.com/rust-lang/cc-rs/commit/57853c4bf8a89a0f4c9137eb367ac580305c6919
This patch is present in version 1.0.80 and newer versions of the cc crate. The rustc source distribution currently has 3 different versions of cc in the vendor directory, only one of which has the necessary fix.
We (the Android Rust toolchain) are currently maintaining local patches to upgrade the cc crate dependency versions, which we would like to upstream.
Furthermore, beyond the specific reason, the cc crate in bootstrap is currently pinned at an old version due to problems in the past when trying to update it. It is worthwhile to figure out and resolve these problems so we can keep the dependency up-to-date.
Other fixes:
As of cc v1.0.78, object files are prefixed with a 16-character hash.
Update src/bootstrap/src/core/build_steps/llvm.rs to account for this to
avoid failures when building libunwind and libcrt. Note that while the hash
prefix was introduced in v1.0.78, in order to determine the names of the
object files without scanning the directory, we rely on the compile_intermediates
method, which was introduced in cc v1.0.86
As of cc v1.0.86, compilation on MacOS uses the -mmacosx-version-min flag.
A long-standing bug in the CMake rules for compiler-rt causes compilation
to fail when this flag is specified. So we add a workaround to suppress this
flag.
Updating to cc v1.0.91 and newer requires fixes to bootstrap unit tests.
The unit tests use targets named "A", "B", etc., which fail a validation
check introduced in 1.0.91 of the cc crate.
|
|
|
|
Fix bootstrap panic when build from tarball
Got this error when build from beta tarball (2024-05-03)
regression of https://github.com/rust-lang/rust/commit/6f4f39a8d56968a1ea120e6903c0640eb2a13ee9
panic info:
```
thread 'main' panicked at src/core/builder.rs:583:25:
`should_run.paths` should correspond to real on-disk paths - use `alias` if there is no relevant path: src/llvm-project/compiler-rt/lib/crt
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: bootstrap::core::builder::ShouldRun::paths::{{closure}}
at ./src/bootstrap/src/core/builder.rs:583:25
3: core::iter::adapters::map::map_fold::{{closure}}
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:89:28
4: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/iter/macros.rs:232:27
5: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:129:9
6: core::iter::traits::iterator::Iterator::for_each
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:817:9
7: alloc::vec::Vec<T,A>::extend_trusted
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:3020:17
8: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_extend.rs:26:9
9: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
10: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter.rs:33:9
11: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:2894:9
12: core::iter::traits::iterator::Iterator::collect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9
13: <alloc::collections::btree::set::BTreeSet<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/collections/btree/set.rs:1191:34
14: core::iter::traits::iterator::Iterator::collect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9
15: bootstrap::core::builder::ShouldRun::paths
at ./src/bootstrap/src/core/builder.rs:578:13
16: bootstrap::core::builder::ShouldRun::path
at ./src/bootstrap/src/core/builder.rs:562:9
17: <bootstrap::core::build_steps::llvm::CrtBeginEnd as bootstrap::core::builder::Step>::should_run
at ./src/bootstrap/src/core/build_steps/llvm.rs:1174:9
18: bootstrap::core::builder::StepDescription::run::{{closure}}
at ./src/bootstrap/src/core/builder.rs:416:25
19: core::iter::adapters::map::map_fold::{{closure}}
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:89:28
20: <core::slice::iter::Iter<T> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/slice/iter/macros.rs:232:27
21: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/adapters/map.rs:129:9
22: core::iter::traits::iterator::Iterator::for_each
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:817:9
23: alloc::vec::Vec<T,A>::extend_trusted
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:3020:17
24: <alloc::vec::Vec<T,A> as alloc::vec::spec_extend::SpecExtend<T,I>>::spec_extend
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_extend.rs:26:9
25: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter_nested::SpecFromIterNested<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
26: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/spec_from_iter.rs:33:9
27: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/alloc/src/vec/mod.rs:2894:9
28: core::iter::traits::iterator::Iterator::collect
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/iter/traits/iterator.rs:2003:9
29: bootstrap::core::builder::StepDescription::run
at ./src/bootstrap/src/core/builder.rs:414:27
30: bootstrap::core::builder::Builder::run_step_descriptions
at ./src/bootstrap/src/core/builder.rs:1047:9
31: bootstrap::core::builder::Builder::execute_cli
at ./src/bootstrap/src/core/builder.rs:1028:9
32: bootstrap::Build::build
at ./src/bootstrap/src/lib.rs:683:17
33: bootstrap::main
at ./src/bootstrap/src/bin/main.rs:79:5
34: core::ops::function::FnOnce::call_once
at /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250:5
```
|
|
add a reference link to the comment of the "cc" and "cmake".
Having a reference link provides more context for the problems of bumping cc and cmake.
|
|
r=Mark-Simulacrum
add support to override lldb binary path for ./x test
When running debuginfo tests I couldn't set custom build of lldb. The `src/bootstrap/src/core/build_steps/test.rs` has "lldb" hardcoded. I ended up hacking `src/bootstrap/src/core/build_steps/test.rs` just to get the tests running the way I wanted.
Then I've found out that we can override `gdb` under [build] section. This PR enables the same for `lldb`
|
|
Change `SIGPIPE` ui from `#[unix_sigpipe = "..."]` to `-Zon-broken-pipe=...`
In the stabilization [attempt](https://github.com/rust-lang/rust/pull/120832) of `#[unix_sigpipe = "sig_dfl"]`, a concern was [raised ](https://github.com/rust-lang/rust/pull/120832#issuecomment-2007394609) related to using a language attribute for the feature: Long term, we want `fn lang_start()` to be definable by any crate, not just libstd. Having a special language attribute in that case becomes awkward.
So as a first step towards the next stabilization attempt, this PR changes the `#[unix_sigpipe = "..."]` attribute to a compiler flag `-Zon-broken-pipe=...` to remove that concern, since now the language is not "contaminated" by this feature.
Another point was [also raised](https://github.com/rust-lang/rust/pull/120832#issuecomment-1987023484), namely that the ui should not leak **how** it does things, but rather what the **end effect** is. The new flag uses the proposed naming. This is of course something that can be iterated on further before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/97889
|
|
|
