about summary refs log tree commit diff
path: root/src/bootstrap/builder.rs
AgeCommit message (Collapse)AuthorLines
2021-03-06Revert fmt version, add rustdoc-json-types to bootstrap testsRune Tynan-0/+1
2021-03-01Rename rustdoc lints to be a tool lint instead of built-in.Joshua Nelson-3/+15
- Rename `broken_intra_doc_links` to `rustdoc::broken_intra_doc_links` - Ensure that the old lint names still work and give deprecation errors - Register lints even when running doctests Otherwise, all `rustdoc::` lints would be ignored. - Register all existing lints as removed This unfortunately doesn't work with `register_renamed` because tool lints have not yet been registered when rustc is running. For similar reasons, `check_backwards_compat` doesn't work either. Call `register_removed` directly instead. - Fix fallout + Rustdoc lints for compiler/ + Rustdoc lints for library/ Note that this does *not* suggest `rustdoc::broken_intra_doc_links` for `rustdoc::intra_doc_link_resolution_failure`, since there was no time when the latter was valid.
2021-03-01Rollup merge of #82480 - jyn514:no-enable-constant, r=Mark-SimulacrumJoshua Nelson-18/+0
Remove `ENABLE_DOWNLOAD_RUSTC` constant `ENABLE_DOWNLOAD_RUSTC` was introduced as part of the MVP for `download-rustc` as a way not to rebuild artifacts that have already been downloaded. Unfortunately, it doesn't work very well: - Steps are ignored by default, which makes it easy to leave out a step that should be built. For example, the MVP forgot to enable any tests, so it was only possible to *build* locally. - It didn't work correctly even when it was enabled: calling `builder.ensure()` would completely ignore the constant and rebuild the step anyway. This has no obvious fix since `ensure()` has to return a `Step::Output`. Instead, this handles `download-rustc` in `impl Step for Rustc` and `impl Step for Std`, which to my knowledge are the only build steps that don't first go through `impl Step for Sysroot` (`Rustc` is used for the `rustc-dev` component). See https://github.com/rust-lang/rust/pull/79540#discussion_r563350075 and https://github.com/rust-lang/rust/issues/81930 for further context. Here are some example runs with these changes and `download-rustc` enabled: ``` $ x.py build src/tools/clippy Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 1m 09s Building stage1 tool cargo-clippy (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.11s $ x.py test src/tools/clippy Finished dev [unoptimized + debuginfo] target(s) in 0.09s Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.09s Building rustdoc for stage1 (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.28s Finished release [optimized] target(s) in 15.26s Running build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/release/deps/clippy_driver-8b407b140e0aa91c test result: ok. 592 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out $ x.py build src/tools/rustdoc Building rustdoc for stage1 (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 41.28s Build completed successfully in 0:00:41 $ x.py test src/test/rustdoc-ui Building stage0 tool compiletest (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.12s Building rustdoc for stage1 (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.10s test result: ok. 105 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.15s $ x.py build compiler/rustc Finished dev [unoptimized + debuginfo] target(s) in 0.09s Build completed successfully in 0:00:00 ``` Note a few things: - Clippy depends on stage1 rustc-dev artifacts, but rustc didn't have to be recompiled. Instead, the artifacts were copied automatically. - All steps are always enabled. There is no danger of forgetting a step, since only the entrypoints have to handle `download-rustc`. - Building the compiler (`compiler/rustc`) automatically does no work. Helps with https://github.com/rust-lang/rust/issues/81930. r? `@Mark-Simulacrum`
2021-03-01Rollup merge of #82532 - pnkfelix:rustbuild-print-step-rusage, r=Mark-SimulacrumYuki Okushi-0/+4
Add `build.print_step_rusage` to config.toml Adds `build.print_step_rusage` to config.toml, which is meant to be an easy way to let compiler developers get feedback on the terminal during bootstrap about resource usage during each step. The output is piggy-backed on `[PRINT-STEP-TIMINGS]`, mostly because the functionality seemed to naturally fit there in the overall control-flow and output structure (even if very little is shared between the implementations themselves). Some sample output (from my Linux box, where I believe the `max rss` output to be somewhat trust-worthy...): ``` [...] Compiling regex v1.4.3 [RUSTC-TIMING] tempfile test:false 0.323 user: 1.418662 sys: 0.81767 max rss (kb): 182084 page reclaims: 26615 page faults: 0 fs block inputs: 0 fs block outputs: 2160 voluntary ctxt switches: 798 involuntary ctxt switches: 131 Completed tempfile v3.1.0 in 0.3s [RUSTC-TIMING] chalk_ir test:false 1.890 user: 1.893603 sys: 0.99663 max rss (kb): 239432 page reclaims: 32107 page faults: 0 fs block inputs: 0 fs block outputs: 25008 voluntary ctxt switches: 108 involuntary ctxt switches: 183 Completed chalk-ir v0.55.0 in 1.9s Compiling rustc_data_structures v0.0.0 (/home/pnkfelix/Dev/Rust/rust.git/compiler/rustc_data_structures) [RUSTC-TIMING] chrono test:false 1.244 user: 3.333198 sys: 0.134963 max rss (kb): 246612 page reclaims: 44857 page faults: 0 fs block inputs: 0 fs block outputs: 11704 voluntary ctxt switches: 1043 involuntary ctxt switches: 326 Completed chrono v0.4.15 in 1.3s [RUSTC-TIMING] rustc_rayon test:false 1.332 user: 1.763912 sys: 0.75996 max rss (kb): 239076 page reclaims: 35285 page faults: 0 fs block inputs: 0 fs block outputs: 19576 voluntary ctxt switches: 359 involuntary ctxt switches: 168 Completed rustc-rayon v0.3.0 in 1.3s Compiling matchers v0.0.1 [RUSTC-TIMING] matchers test:false 0.100 user: 0.94495 sys: 0.15119 max rss (kb): 140076 page reclaims: 8200 page faults: 0 fs block inputs: 0 fs block outputs: 392 voluntary ctxt switches: 43 involuntary ctxt switches: 12 Completed matchers v0.0.1 in 0.1s [...] ```
2021-03-01Rollup merge of #82309 - jyn514:rustdocflags, r=Mark-SimulacrumYuki Okushi-9/+21
Propagate RUSTDOCFLAGS in the environment when documenting Previously, RUSTDOCFLAGS would get overriden when bootstrap set `RUSTDOCFLAGS` itself. Propagate the flag manually, using the same logic as `RUSTFLAGS`. Fixes https://github.com/rust-lang/rust/issues/75256.
2021-02-25Created experimental build.print_step_rusage settingFelix S. Klock II-0/+4
Intended to piggy-back on output from existing build.print_step_timings setting.
2021-02-24Remove `ENABLE_DOWNLOAD_RUSTC` constantJoshua Nelson-18/+0
This was introduced as part of the MVP for `download-rustc`. Unfortunately, it doesn't work very well: - Steps are ignored by default, which makes it easy to leave out a step that should be built. For example, the MVP forgot to enable any tests, so it was *only* possible to build locally. - It didn't work correctly even when it was enabled: calling `builder.ensure()` would completely ignore the constant and rebuild the step anyway. This has no obvious fix since `ensure()` has to return a `Step::Output`. Instead, this handles `download-rustc` in `impl Step for Rustc` and `impl Step for Std`, which to my knowledge are the only build steps that don't first go through `impl Step for Sysroot` (`Rustc` is used for the `rustc-dev` component). See https://github.com/rust-lang/rust/pull/79540#discussion_r563350075 and https://github.com/rust-lang/rust/issues/81930 for further context. Here are some example runs with these changes and `download-rustc` enabled: ``` $ x.py build src/tools/clippy Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 1m 09s Building stage1 tool cargo-clippy (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.11s $ x.py test src/tools/clippy Updating only changed submodules Submodules updated in 0.01 seconds Finished dev [unoptimized + debuginfo] target(s) in 0.09s Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.09s Building rustdoc for stage1 (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.28s Finished release [optimized] target(s) in 15.26s Running build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/release/deps/clippy_driver-8b407b140e0aa91c test result: ok. 592 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out $ x.py build src/tools/rustdoc Building rustdoc for stage1 (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 41.28s Build completed successfully in 0:00:41 $ x.py test src/test/rustdoc-ui Building stage0 tool compiletest (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.12s Building rustdoc for stage1 (x86_64-unknown-linux-gnu) Finished release [optimized] target(s) in 0.10s test result: ok. 105 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.15s $ x.py build compiler/rustc Finished dev [unoptimized + debuginfo] target(s) in 0.09s Build completed successfully in 0:00:00 ``` Note a few things: - Clippy depends on stage1 rustc-dev artifacts, but rustc didn't have to be recompiled. Instead, the artifacts were copied automatically. - All steps are always enabled. There is no danger of forgetting a step, since only the entrypoints have to handle `download-rustc`. - Building the compiler (`compiler/rustc`) automatically does no work.
2021-02-23Auto merge of #82076 - jyn514:update-bootstrap, r=Mark-Simulacrumbors-11/+3
Update the bootstrap compiler This updates the bootstrap compiler, notably leaving out a change to enable semicolon in macro expressions lint, because stdarch still depends on the old behavior.
2021-02-21Propagate RUSTDOCFLAGS in the environment when documentingJoshua Nelson-9/+21
Previously, RUSTDOCFLAGS would get overriden when bootstrap set `RUSTDOCFLAGS` itself. Propagate the flag manually, using the same logic as `RUSTFLAGS`. This also extracts the logic into a helper function to make sure it's the same.
2021-02-21Add new rustdoc-gui test suiteGuillaume Gomez-0/+1
2021-02-20Use the new name for `split-debuginfo`Joshua Nelson-11/+3
2021-02-20Don't apply semicolon in expressions from macros yetMark Rousskov-1/+6
std_detect is still using this and as it's in a submodule updating it will be a pain. We can catch this either after a stdarch submodule bump or just on the next cycle.
2021-02-20Update the bootstrap compilerJoshua Nelson-6/+1
Note this does not change `core::derive` since it was merged after the beta bump.
2021-02-15Rollup merge of #82106 - jyn514:cleanup-bootstrap, r=Mark-SimulacrumJonas Schievink-2/+1
Remove unnecessary `Option` in `default_doc` Previously, there were two different ways to encode the same info: `None` or `Some(&[])`. Now there is only one way, `&[]`.
2021-02-14Remove unnecessary `Option` in `default_doc`Joshua Nelson-2/+1
Previously, there two different ways to encode the same info: `None` or `Some(&[])`. Now there is only one way, `&[]`.
2021-02-10Rollup merge of #81910 - jyn514:bootstrap-1.52, r=jackh726Yuki Okushi-1/+1
Use format string in bootstrap panic instead of a string directly This fixes the following warning when compiling with nightly: ``` warning: panic message is not a string literal --> src/bootstrap/builder.rs:1515:24 | 1515 | panic!(out); | ^^^ | = note: `#[warn(non_fmt_panic)]` on by default = note: this is no longer accepted in Rust 2021 help: add a "{}" format string to Display the message | 1515 | panic!("{}", out); | ^^^^^ help: or use std::panic::panic_any instead | 1515 | std::panic::panic_any(out); | ^^^^^^^^^^^^^^^^^^^^^^ ``` Found while working on https://github.com/rust-lang/rust/pull/79540. cc https://github.com/rust-lang/rust/pull/81645, which landed in 1.51.
2021-02-08Absolute bare minimum for downloading rustc from CIJoshua Nelson-2/+24
- Use the same compiler for stage0 and stage1. This should be fixed at some point (so bootstrap isn't constantly rebuilt). - Make sure `x.py build` and `x.py check` work. - Use `git merge-base` to determine the most recent commit to download. - Copy stage0 to the various sysroots in `Sysroot`, and delegate to Sysroot in Assemble. Leave all other code unchanged. - Rename date -> key This can also be a commit hash, so 'date' is no longer a good name. - Add the commented-out option to config.toml.example - Disable all steps by default when `download-rustc` is enabled Most steps don't make sense when downloading a compiler, because they'll be pre-built in the sysroot. Only enable the ones that might be useful, in particular Rustdoc and all `check` steps. At some point, this should probably enable other tools, but rustdoc is enough to test out `download-rustc`. - Don't print 'Skipping' twice in a row Bootstrap forcibly enables a dry run if it isn't already set, so previously it would print the message twice: ``` Skipping bootstrap::compile::Std because it is not enabled for `download-rustc` Skipping bootstrap::compile::Std because it is not enabled for `download-rustc` ``` Now it correctly only prints once. ## Future work - Add FIXME about supporting beta commits - Debug logging will never work. This should be fixed.
2021-02-08Use format string in bootstrap panic instead of a string directlyJoshua Nelson-1/+1
This fixes the following warning when compiling with nightly: ``` warning: panic message is not a string literal --> src/bootstrap/builder.rs:1515:24 | 1515 | panic!(out); | ^^^ | = note: `#[warn(non_fmt_panic)]` on by default = note: this is no longer accepted in Rust 2021 help: add a "{}" format string to Display the message | 1515 | panic!("{}", out); | ^^^^^ help: or use std::panic::panic_any instead | 1515 | std::panic::panic_any(out); | ^^^^^^^^^^^^^^^^^^^^^^ ```
2021-01-29Rollup merge of #79819 - Aaron1011:feature/macro-trailing-semicolon, ↵Yuki Okushi-0/+6
r=petrochenkov Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint cc #79813 This PR adds an allow-by-default future-compatibility lint `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a macro body is ignored due to the macro being used in expression position: ```rust macro_rules! foo { () => { true; // WARN } } fn main() { let val = match true { true => false, _ => foo!() }; } ``` The lint takes its level from the macro call site, and can be allowed for a particular macro by adding `#[allow(macro_trailing_semicolon)]`. The lint is set to warn for all internal rustc crates (when being built by a stage1 compiler). After the next beta bump, we can enable the lint for the bootstrap compiler as well.
2021-01-28rustc: Stabilize `-Zrun-dsymutil` as `-Csplit-debuginfo`Alex Crichton-3/+11
This commit adds a new stable codegen option to rustc, `-Csplit-debuginfo`. The old `-Zrun-dsymutil` flag is deleted and now subsumed by this stable flag. Additionally `-Zsplit-dwarf` is also subsumed by this flag but still requires `-Zunstable-options` to actually activate. The `-Csplit-debuginfo` flag takes one of three values: * `off` - This indicates that split-debuginfo from the final artifact is not desired. This is not supported on Windows and is the default on Unix platforms except macOS. On macOS this means that `dsymutil` is not executed. * `packed` - This means that debuginfo is desired in one location separate from the main executable. This is the default on Windows (`*.pdb`) and macOS (`*.dSYM`). On other Unix platforms this subsumes `-Zsplit-dwarf=single` and produces a `*.dwp` file. * `unpacked` - This means that debuginfo will be roughly equivalent to object files, meaning that it's throughout the build directory rather than in one location (often the fastest for local development). This is not the default on any platform and is not supported on Windows. Each target can indicate its own default preference for how debuginfo is handled. Almost all platforms default to `off` except for Windows and macOS which default to `packed` for historical reasons. Some equivalencies for previous unstable flags with the new flags are: * `-Zrun-dsymutil=yes` -> `-Csplit-debuginfo=packed` * `-Zrun-dsymutil=no` -> `-Csplit-debuginfo=unpacked` * `-Zsplit-dwarf=single` -> `-Csplit-debuginfo=packed` * `-Zsplit-dwarf=split` -> `-Csplit-debuginfo=unpacked` Note that `-Csplit-debuginfo` still requires `-Zunstable-options` for non-macOS platforms since split-dwarf support was *just* implemented in rustc. There's some more rationale listed on #79361, but the main gist of the motivation for this commit is that `dsymutil` can take quite a long time to execute in debug builds and provides little benefit. This means that incremental compile times appear that much worse on macOS because the compiler is constantly running `dsymutil` over every single binary it produces during `cargo build` (even build scripts!). Ideally rustc would switch to not running `dsymutil` by default, but that's a problem left to get tackled another day. Closes #79361
2021-01-28Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lintAaron Hill-0/+6
cc #79813 This PR adds an allow-by-default future-compatibility lint `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS`. It fires when a trailing semicolon in a macro body is ignored due to the macro being used in expression position: ```rust macro_rules! foo { () => { true; // WARN } } fn main() { let val = match true { true => false, _ => foo!() }; } ``` The lint takes its level from the macro call site, and can be allowed for a particular macro by adding `#[allow(semicolon_in_expressions_from_macros)]`. The lint is set to warn for all internal rustc crates (when being built by a stage1 compiler). After the next beta bump, we can enable the lint for the bootstrap compiler as well.
2021-01-10Make `--color always` apply to logging tooJoshua Nelson-0/+10
2020-12-31bootstrap: clippy fixesMatthias Krüger-1/+1
addresses: clippy::or_fun_call clippy::single_char_add_str clippy::comparison_to_empty clippy::or_fun_call
2020-12-30Bump bootstrap compiler to 1.50 betaMark Rousskov-4/+1
2020-12-29Remove `compile-fail` test suiteVadim Petrochenkov-1/+0
2020-12-23Auto merge of #80262 - Mark-Simulacrum:pgo-rustc, r=pietroalbinibors-0/+1
Utilize PGO for rustc linux dist builds This implements support for applying PGO to the rustc compilation step (not standard library or any tooling, including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater implementation time commitment, implementing for platforms outside of x86_64-unknown-linux-gnu is skipped. In practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary, but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore, cargo (and its dependencies), and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial, but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI, though, so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least, giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour with this PR, up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially, in the future, on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost. r? `@michaelwoerister` (but tell me if you don't want to / don't feel comfortable approving and we can find others)
2020-12-22Utilize PGO for rustc linux dist buildsMark Rousskov-0/+1
This implements support for applying PGO to the rustc compilation step (not standard library or any tooling, including rustdoc). Expanding PGO to more tools is not terribly difficult but will involve more work and greater CI time commitment. For the same reason of avoiding greater time commitment, this currently avoids implementing for platforms outside of x86_64-unknown-linux-gnu, though in practice it should be quite simple to extend over time to more platforms. The initial implementation is intentionally minimal here to avoid too much work investment before we start seeing wins for a subset of Rust users. The choice of workloads to profile here is somewhat arbitrary, but the general rationale was to aim for a small set that largely avoided time regressions on perf.rust-lang.org's full suite of crates. The set chosen is libcore, cargo (and its dependencies), and a few ad-hoc stress tests from perf.rlo. The stress tests are arguably the most controversial, but they benefit those cases (avoiding regressions) and do not really remove wins from other benchmarks. The primary next step after this PR lands is to implement support for PGO in LLVM. It is unclear whether we can afford a full LLVM rebuild in CI, though, so the approach taken there may need to be more staggered. rustc-only PGO seems well affordable on linux at least, giving us up to 20% wall time wins on some crates for 15 minutes of extra CI time (1 hour up from 45 minutes). The PGO data is uploaded to allow others to reuse it if attempting to reproduce the CI build or potentially, in the future, on other platforms where an off-by-one strategy is used for dist builds at minimal performance cost.
2020-12-20Skip `dsymutil` by default for compiler bootstrapJ. Ryan Stinnett-0/+13
`dsymutil` adds time to builds on Apple platforms for no clear benefit, and also makes it more difficult for debuggers to find debug info. The compiler currently defaults to running `dsymutil` to preserve its historical default, but when compiling the compiler itself, we skip it by default since we know it's safe to do so in that case.
2020-12-12Fix building compiler docs with stage 0Joshua Nelson-1/+4
2020-12-01Add tests for rustdoc jsonNixon Enraght-Moony-0/+1
Move rustdoc/rustdoc-json to rustdoc-json Scaffold rustdoc-json test mode Implement run_rustdoc_json_test Fix up python Make tidy happy
2020-12-01Rollup merge of #79525 - jyn514:feature-gate-normalize, r=GuillaumeGomezMara Bos-0/+1
Add -Z normalize-docs and enable it for compiler docs Works around https://github.com/rust-lang/rust/issues/79459 by only enabling normalization for the compiler itself (and anyone who opts-in on nightly). Eventually I want to remove this and enable normalization by default, but that's turned out to be [really hard](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20do.20I.20normalize.20projection.20types.20to.20a.20single.20type.3F/near/218125195). This uses a command line option instead of a feature gate so it's easier to pass it to all crates at once. Theoretically it's better to use a feature gate instead so that it's easier for people to use on docs.rs, but I'm also not terribly concerned with how easy it to use a temporary hack. Addresses https://github.com/rust-lang/rust/issues/77459.
2020-11-29Add -Z normalize-docs and enable it for compiler docsJoshua Nelson-0/+1
2020-11-28lint-docs: Add --validate flag to validate lint docs separately.Eric Huss-0/+1
2020-11-12Add `--color` support to bootstrapJoshua Nelson-1/+11
This allows using bootstrap with https://github.com/Canop/bacon.
2020-11-11Rollup merge of #78354 - 12101111:rustbuild_profiler, r=Mark-SimulacrumJonas Schievink-2/+2
Support enable/disable sanitizers/profiler per target This PR add options under `[target.*]` of `config.toml` which can enable or disable sanitizers/profiler runtime for corresponding target. If these options are empty, the global options under `[build]` will take effect. Fix #78329
2020-11-09Auto merge of #78201 - joshtriplett:rustc-tls-model, r=Mark-Simulacrumbors-0/+8
Compile rustc crates with the initial-exec TLS model This should produce more efficient code, with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen, but that shouldn't be a problem for rustc's internal libraries.
2020-11-06Compile tools and internal libraries with the initial-exec TLS modelJosh Triplett-0/+8
This should produce more efficient code, with fewer calls to __tls_get_addr. The tradeoff is that libraries using it won't work with dlopen, but that shouldn't be a problem for tools or for our own internal libraries. Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
2020-11-06Auto merge of #77351 - jyn514:clippy-sysroot, r=Mark-Simulacrumbors-4/+42
Fix `x.py clippy` I don't think this ever worked. Fixes https://github.com/rust-lang/rust/issues/77309. `--fix` support is a work in progress, but works for a very small subset of `libtest`. This works by using the host `cargo-clippy` driver; it does not use `stage0.txt` at all. To mitigate confusion from this, it gives an error if you don't have `rustc +nightly` as the default rustc in `$PATH`. Additionally, it means that bootstrap can't set `RUSTC`; this makes it no longer possible for clippy to detect the sysroot itself. Instead, bootstrap passes the sysroot to cargo. r? `@ghost`
2020-11-05Get `--fix` working for everything except rustdocJoshua Nelson-4/+3
Here's the error for rustdoc: ``` Checking rustdoc artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) error: no library targets found in package `rustdoc-tool` ```
2020-11-03build-manifest: remove legacy promote-release supportPietro Albini-1/+0
This commit removes support for the legacy promote-release, as that's not executed anymore on the nightly channel.
2020-10-26Allow using clippy with either beta or nightlyJoshua Nelson-5/+7
Not 100% sure this will _always_ work, but it works currently.
2020-10-26Add --fix support to `x.py clippy`Joshua Nelson-2/+2
2020-10-26Set the proper sysroot for clippyJoshua Nelson-2/+39
Clippy does its own runtime detection of the sysroot, which was incorrect in this case (it used the beta sysroot). This overrides the sysroot to use `stage0-sysroot` instead. - Get `x.py clippy` to work on nightly - Give a nice error message if nightly clippy isn't installed
2020-10-26Add support for using cg_clif to bootstrap rustcbjorn3-5/+32
2020-10-26Support enable/disable sanitizers/profiler per target12101111-2/+2
2020-10-12bootstrap: add --include-default-paths to ./x.pyPietro Albini-21/+21
2020-10-12bootstrap: add disabled by default build-manifest dist componentPietro Albini-0/+1
2020-10-05Remove the rust stuff and just make it a simple shell scriptCassandra Fridkin-1/+1
It's ok, now I'm writing enough Rust that i'm able to get my fix elsewhere
2020-10-05Merge branch 'master' into hooksCassandra Fridkin-72/+46
2020-10-05Rollup merge of #77407 - pietroalbini:less-build-manifest, r=Mark-SimulacrumDylan DPC-1/+1
Improve build-manifest to work with the improved promote-release This PR makes some changes to build-manifest to have it work better with the other improvements I'm making to [promote-release](https://github.com/rust-lang/promote-release). A new way to invoke the tool was added: `./x.py run src/tools/build-manifest`. The new invocation disables the generation of `.sha256` files and the generation of GPG signatures, as those steps are not tied to the Rust version we're building the manifest of: handling them in `promote-release` will improve the maintenability of our release process. Invocations through the old command (`./x.py dist hash-and-sign`) are referred inside the source code as "legacy". The new invocation also enables internal parallelism, disabled on legacy to avoid overloading our old server. Improvements were also made on how the checksums included in the manifest are generated: * The manifest is first generated with placeholder checksums, and then a function walks through the manifes and calculates only the needed hashes. Before this PR, all the hashes were calculated beforehand, including the hashes of unused files. * Calculating the hashes is now done in parallel with rayon, to better utilize all the available disk bandwidth. * The `sha2` crate is now used instead of the `sha256sum` CLI tool: this avoids the overhead of calling another process, but more importantly enables hardware acceleration whenever available (the `sha256sum` CLI tool doesn't support it at all). r? @Mark-Simulacrum This PR is best reviewed commit-by-commit.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 09:54:33 +0000