about summary refs log tree commit diff
path: root/src/bootstrap/dist.rs
AgeCommit message (Collapse)AuthorLines
2021-06-10gcc-lld mvp1000teslas-0/+4
ignore test if rust-lld not found create ld -> rust-lld symlink at build time instead of run time for testing in ci copy instead of symlinking remove linux check test for linker, suggestions from bjorn3 fix overly restrictive lld matcher use -Zgcc-ld flag instead of -Clinker-flavor refactor code adding lld to gcc path revert ci changes suggestions from petrochenkov rename gcc_ld to gcc-ld in dirs
2021-04-17bootstrap: Restore missing --bulk-dirs for rust-docs, rustc-docsAnders Kaseorg-2/+2
The --bulk-dirs argument was removed for rust-docs in commit c768ce138427b1844c1f6594daba9c0e33928032 and rustc-docs in commit 8ca46fc7a83734c9622f11f25d16b82316f44bcc (#79788), presumably by mistake; that slowed down installation of rust-docs from under a second to some twenty *minutes*. Restoring --bulk-dirs reverses this slowdown. Fixes #80684. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
2021-04-03Address review comments and Windows failure, and make cleanerRich Kadel-24/+28
2021-04-03Make rust-demangler installableRich Kadel-0/+86
Adds bootstrap rules to support installing rust-demangler. When compiling with `-Z instrument-coverage`, the coverage reports are generated by `llvm-cov`. `llvm-cov` includes a built-in demangler for C++, and an option to supply an alternate demangler. For Rust, we have `rust-demangler`, currently used in `rustc` coverage tests. Fuchsia's toolchain for Rust is built via `./x.py install`. Fuchsia is adding support for Rust coverage, and we need to include the `rust-demangler` in the installed `bin` directory. Configured rust-demangler as an in-tree extended tool. Added tests to support `./x.py test rust-demangler`. Install with extended tools by default only if `profiler = true`.
2021-02-15Rollup merge of #82106 - jyn514:cleanup-bootstrap, r=Mark-SimulacrumJonas Schievink-2/+2
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/+2
Previously, there two different ways to encode the same info: `None` or `Some(&[])`. Now there is only one way, `&[]`.
2021-02-11dist: include src/build_helper as part of the crate graph for rustc-dev.Benjamin Bouvier-0/+8
Since it was missing, it wasn't possible to really use rustc-dev to build, see for instance: https://github.com/rust-analyzer/rust-analyzer/issues/7589.
2021-01-15Allow downloading LLVM on WindowsJoshua Nelson-18/+30
- Don't ignore packaging `llvm/lib/` for `rust-dev` when LLVM is linked statically - Add `link-type.txt` so bootstrap knows whether llvm was linked statically or dynamically - Don't assume CI LLVM is linked dynamically in `bootstrap::config` - Fall back to dynamic linking if `link-type.txt` doesn't exist - Fix existing bug that split the output of `llvm-config` on lines, not spaces - Enable building LLVM tests This works around the following llvm bug: ``` llvm-config: error: component libraries and shared library llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libgtest_main.a llvm-config: error: missing: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/lib/libLLVMTestingSupport.a thread 'main' panicked at 'command did not execute successfully: "/home/joshua/rustc2/build/x86_64-unknown-linux-gnu/llvm/build/bin/llvm-config" "--libfiles" ``` I'm not sure why llvm-config thinks these are required, but to avoid the error, this builds them anyway. - Temporarily set windows as the try builder. This should be reverted before merging. - Bump version of `download-ci-llvm-stamp` `src/llvm-project` hasn't changed, but the generated tarball has. - Only special case MacOS when dynamic linking. Static linking works fine. - Store `link-type.txt` to the top-level of the tarball This allows writing the link type unconditionally. Previously, bootstrap had to keep track of whether the file IO *would* succeed (it would fail if `lib/` didn't exist), which was prone to bugs. - Make `link-type.txt` required Anyone downloading this from CI should be using a version of bootstrap that matches the version of the uploaded artifacts. So a missing link-type indicates a bug in x.py.
2021-01-05Rollup merge of #80533 - matthiaskrgr:bootstrap_clppy, r=Mark-SimulacrumYuki Okushi-4/+4
bootstrap: clippy fixes addresses: clippy::or_fun_call clippy::single_char_add_str clippy::comparison_to_empty clippy::or_fun_call
2020-12-31bootstrap: use the correct paths during ./x.py installPietro Albini-2/+2
2020-12-31bootstrap: change the dist outputs to GeneratedTarballPietro Albini-38/+38
The struct will allow to store more context on the generated tarballs.
2020-12-31bootstrap: never delete the tarball temporary directoryPietro Albini-2/+2
Files in the temporary directory are used by ./x.py install.
2020-12-31bootstrap: clippy fixesMatthias Krüger-4/+4
addresses: clippy::or_fun_call clippy::single_char_add_str clippy::comparison_to_empty clippy::or_fun_call
2020-12-23bootstrap: convert reproducible-artifacts to use TarballPietro Albini-41/+4
2020-12-23bootstrap: use the normal compiler to build stdPietro Albini-2/+1
2020-12-23bootstrap: avoid producing the rust tarball during dry runsPietro Albini-0/+5
2020-12-23bootstrap: convert rustc-src to use TarballPietro Albini-31/+3
2020-12-23bootstrap: convert rust to use TarballPietro Albini-38/+5
2020-12-23bootstrap: convert rust-src to use TarballPietro Albini-27/+3
2020-12-23bootstrap: convert rust-analyzer to use TarballPietro Albini-50/+6
2020-12-23bootstrap: convert rls to use TarballPietro Albini-50/+6
2020-12-23bootstrap: convert rustfmt to use TarballPietro Albini-49/+7
2020-12-23bootstrap: convert miri to use TarballPietro Albini-51/+7
2020-12-23bootstrap: simplify including licenses and readmes to tarballsPietro Albini-8/+2
2020-12-23bootstrap: convert clippy to use TarballPietro Albini-48/+10
2020-12-23bootstrap: convert cargo to use TarballPietro Albini-56/+15
2020-12-23bootstrap: convert rust-analysis to use TarballPietro Albini-36/+12
2020-12-23bootstrap: convert rustc-dev to use TarballPietro Albini-40/+16
2020-12-23bootstrap: convert rust-std to use TarballPietro Albini-30/+8
2020-12-23bootstrap: refactor showing the "dist" infoPietro Albini-21/+0
2020-12-23bootstrap: convert rustc to use TarballPietro Albini-52/+8
2020-12-23bootstrap: convert rust-mingw to use TarballPietro Albini-23/+5
2020-12-23bootstrap: convert rustc-docs to use TarballPietro Albini-34/+8
2020-12-23bootstrap: convert rust-docs to use TarballPietro Albini-34/+11
2020-12-23bootstrap: convert llvm-tools to use TarballPietro Albini-37/+7
2020-12-23bootstrap: convert build-manifest to use the new Tarball structPietro Albini-88/+21
2020-12-23Auto merge of #80262 - Mark-Simulacrum:pgo-rustc, r=pietroalbinibors-0/+69
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/+69
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-18Auto merge of #80081 - ehuss:update-cargo, r=Mark-Simulacrumbors-0/+6
Update cargo 4 commits in d274fcf862b89264fa2c6b917b15230705257317..a3c2627fbc2f5391c65ba45ab53b81bf71fa323c 2020-12-07 23:08:44 +0000 to 2020-12-14 17:21:26 +0000 - Check if rerun-if-changed points to a directory. (rust-lang/cargo#8973) - Implement external credential process. (RFC 2730) (rust-lang/cargo#8934) - Revert recent build-std vendoring changes (rust-lang/cargo#8968) - Fix the unit dependency graph with dev-dependency `links` (rust-lang/cargo#8969)
2020-12-18Update cargoEric Huss-0/+6
2020-12-17Rollup merge of #80082 - ehuss:revert-rust-src-vendor, r=Mark-SimulacrumYuki Okushi-24/+2
Revert #78790 - rust-src vendoring This reverts the rust-src vendor changes from #78790. There were a few issues (see #79218, https://github.com/rust-lang/cargo/issues/8962, https://github.com/rust-lang/cargo/issues/8963), that I don't think will get fixed in the next few days before the beta branch. Fixes #79218
2020-12-16bootstrap: include llvm-dwp in CI LLVMDavid Wood-0/+1
This commit includes the `llvm-dwp` tool in the CI LLVM (which rustc developers can download instead of building LLVM locally) - `llvm-dwp` is required by Split DWARF which landed in PR #77117. Signed-off-by: David Wood <david@davidtw.co>
2020-12-16Revert "Auto merge of #78790 - Gankra:rust-src-vendor, r=Mark-Simulacrum"Eric Huss-24/+2
This reverts commit 7afc5172305cdae588a0318ce545749cf4ed947d, reversing changes made to d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f.
2020-12-16bootstrap: copy `llvm-dwp` to sysrootDavid Wood-6/+9
`llvm-dwp` is required for linking the DWARF objects into DWARF packages when using Split DWARF, especially given that rustc produces multiple DWARF objects (one for each codegen unit). Signed-off-by: David Wood <david@davidtw.co>
2020-12-11use strip_prefix over slicing (clippy::manual_strip)Matthias Krüger-1/+1
2020-11-23Convert UNC path to local path to satisfy install script on WindowsJoseph Rafael Ferrer-1/+5
2020-11-18Revert "Auto merge of #79132 - pietroalbini:beta-next, r=Mark-Simulacrum"Pietro Albini-7/+1
This was landed on master instead of beta!
2020-11-17Ignore failures of RLS on aarch64 WindowsMark Rousskov-1/+7
2020-11-17Install CI llvm into the library directoryMark Rousskov-1/+4
2020-11-17Avoid installing external LLVM dylibsMark Rousskov-0/+16
If the LLVM was externally provided, then we don't currently copy artifacts into the sysroot. This is not necessarily the right choice (in particular, it will require the LLVM dylib to be in the linker's load path at runtime), but the common use case for external LLVMs is distribution provided LLVMs, and in that case they're usually in the standard search path (e.g., /usr/lib) and copying them here is going to cause problems as we may end up with the wrong files and isn't what distributions want. This behavior may be revisited in the future though.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 07:08:30 +0000