Historically, Rust's Fuchsia targets have been labeled x86_64-fuchsia
and aarch64-fuchsia. However, they should technically contain vendor
information. This CL changes Fuchsia's target triples to include the
"unknown" vendor since Clang now does normalization and handles all
triple spellings.
This was previously attempted in #90510, which was closed due to
inactivity.
This duplicates mingw-check into two jobs where one job
runs `tidy` only while the other job does not. The tidy
job will not cancel other jobs on failure.
Re-enable ThinLTO for rustc on `x86_64-apple-darwin`
ThinLTO was disabled on x64 mac in https://github.com/rust-lang/rust/pull/105646 because of the https://github.com/rust-lang/rust/issues/105637 regression.
It was later discovered that the issue was present on other targets as well, as the mac revert was already landing. The linux/win reverts, however, did not land before the root cause was identified.
https://github.com/rust-lang/rust/pull/105800 fixed the underlying issue in `-Zdylib-lto` handling, and the x64 msvc and linux targets are now fixed, ICEs are using the correct `rustc_driver` panic hook.
This PR re-enables ThinLTO on mac for improved perf now that the issue should be fixed everywhere.
Run `x test tidy` sooner in mingw-check
It takes less time to run than the other tests and is more likely to fail. `expand-yaml-anchors` is still run first to make sure the CI files are internally consistent.
Note that changing to `--stage 0` doesn't actually do anything since bootstrap tools are always built with the bootstrap compiler, this just makes it less confusing.
cc https://github.com/rust-lang/rust/pull/105058/commits/83bab41b5b2d4752d187dd91b05c88ac74cf3783
It takes less time to run than the other tests and is more likely to fail.
`expand-yaml-anchors` is still run first to make sure the CI files are internally consistent.
Enable ThinLTO for rustc on `x86_64-apple-darwin`
Local measurements seemed to show an improvement on a couple benchmarks, so I'd like to test real CI builds, and see if the builder doesn't timeout with the expected slight increase in build times.
Let's start with x64 rustc ThinLTO, and then figure out the file structure to configure LLVM ThinLTO. Maybe we'll then try `aarch64` builds since that also looked good locally.
Enable ThinLTO for rustc on x64 msvc
This applies the great work from `@bjorn3` and `@Kobzol` in https://github.com/rust-lang/rust/pull/101403 to x64 msvc.
Here are the local results for the try build `68c5c85ed759334a11f0b0e586f5032a23f85ce4`, compared to its parent `0a6b941df3`. Looking better than my previous local builds.
(I can't show cycle counts, as that option is failing on the windows version of the perf collector, but I'll try to analyze and debug this soon)
This will be the first of a few tests for rustc / llvm / both ThinLTO on the windows and mac targets.
Enable profiler in dist-powerpc64le-linux
Build the profiler runtime to allow using -C profile-generate and -C instrument-coverage on POWER little endian systems.
I have verified locally that the runtime builds and the profiler is working fine on the platform.
Similar pull request for a different system: https://github.com/rust-lang/rust/pull/104304
Build the profiler runtime to allow using -C profile-generate and -C instrument-coverage on POWER systems.
I have verified locally that the runtime builds and the profiler is working fine on the platform.
CI: reduce docker image sizes
Reduces docker image sizes by using simple tips like: cleaning packet managers cache, squashing sequential installation steps into one.
For some images this gives ~40mb for apt-based images (not so much), but ~200mb(!) for centos one.
Rollup of 10 pull requests
Successful merges:
- #104465 (Document more settings for building rustc for Fuchsia)
- #104951 (Simplify checking for `GeneratorKind::Async`)
- #104959 (Revert #104269 (to avoid spurious hang/test failure in CI))
- #104978 (notify the rust-analyzer team on changes to the rust-analyzer subtree)
- #105010 (Fix documentation of asymptotic complexity for rustc_data_structures::SortedMap)
- #105016 (Add sentence when rustdoc search is running)
- #105020 (rustdoc: merge background-image rules in rustdoc-toggle CSS)
- #105024 (rustdoc: remove `fnname` CSS class that's styled exactly like `fn`)
- #105027 (Rustdoc-Json: Add tests for linking to foreign variants.)
- #105038 (Clean up pr 104954)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Document more settings for building rustc for Fuchsia
This documents that you need to link for Fuchsia with `lld` and provides configuration settings for both `clang` and `lld`. It also adjusts the documentation for running the test suite to recommend installing to a prefix.
r? ``@tmandry``
Enable profiler in dist-riscv64-linux
Build the profiler runtime to allow using -C profile-generate and -C instrument-coverage on riscv64-linux.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Build macOS distribution artifacts with XCode 13
After all of the `rust-lang/rust` Apple runners started using macOS 12, the builds created by CI began to use XCode 14.0.1. Due to this (as far as we can tell), XCode's build tools started to ignore the `MACOSX_DEPLOYMENT_TARGET` being defined by us for the distributed builds that let both `rustc` and `libstd` work on older versions. The current idea is that since XCode 14's macOS SDK doesn't support deployment targets before 10.13, it uses some default of its own. You can see the difference between stable's and the most recent nighty's supported versions [here](https://github.com/rust-lang/rust/issues/104570#issuecomment-1321225907).
I wasn't able to confirm my SDK versioning hypothesis locally since I think there's something jammed with my XCode installation, but hopefully this should still fix it for releases.
Closes https://github.com/rust-lang/rust/issues/104570
r? `@Mark-Simulacrum`
Use clang for the UEFI targets
This fixes an issue where the C and asm sources built by compiler_builtins were being compiled as ELF objects instead of PE objects. This wasn't noticed before because it doesn't cause compiler_builtins or rustc to fail to build. You only see a failure when a program is built that references one of the symbols in an ELF object.
Compiling with clang fixes this because the cc crate converts the UEFI targets into Windows targets that clang understands, causing it to produce PE objects.
Also update compiler_builtins to 0.1.84 to pull in some necessary fixes for compiling the UEFI targets with clang.
Fixes https://github.com/rust-lang/rust/issues/104326
This fixes an issue where the C and asm sources built by
compiler_builtins were being compiled as ELF objects instead of PE
objects. This wasn't noticed before because it doesn't cause
compiler_builtins or rustc to fail to build. You only see a failure when
a program is built that references one of the symbols in an ELF object.
Compiling with clang fixes this because the `cc` crate converts the UEFI
targets into Windows targets that clang understands, causing it to
produce PE objects.
Note that this requires compiler_builtins >= 0.1.84.
Fixes https://github.com/rust-lang/rust/issues/104326
Don't focus on notable trait parent when hiding it
I clicked on a notable trait icon so the popup remained and then clicked on the settings menu. When the settings menu was blurred, it scrolled back to when the notable trait was, which isn't great.
r? `@notriddle`
Build the profiler runtime to allow using -C profile-generate
and -C instrument-coverage on riscv64-linux.
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
Enable profiler in dist-s390x-linux
Build the profiler runtime to allow using -C profile-generate and -C instrument-coverage on s390x-linux.
I've verified in a local build that the runtime builds and the profiler is working fine on the platform.
ci: Upgrade dist-x86_64-netbsd to NetBSD 9.0
This is another step in toolchain upgrades for LLVM 16, which will need at least GCC 7.1.
Our previous NetBSD 8.0 cross-toolchain used its system GCC 5.5. While there are newer versions available in pkgsrc, I could not get those working for cross-compilation. Upgrading to NetBSD 9.0 gets us GCC 7.4, which is sufficient for now.
This will affect the compatibility of the build we ship for `x86_64-unknown-netbsd`, but others may still build their own from source if that is needed. It is expected that NetBSD 8 will reach EOL soon anyway, approximately one month after 10 is released, but there is no firm date for that.
