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.
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.
Reduce default configuration's dependency upon static libstdcpp library (#103606)
Fixes#103606
Remove default dependency on static libstdcpp except during dist llvm builds (where we want static libraries so `libLLVM.so` is self-contained).
Usually, we do want to use the static C++ library when building rustc_llvm, but do not want to have that dependency at compiler runtime. Change the defaults to Make It So.
Add check in GUI test for file loading failure
Since https://github.com/rust-lang/rust/pull/101702, some resources location need to be updated in case their content changed because then their hash will change too. This will prevent errors like https://github.com/rust-lang/rust/pull/104114 to happen again.
The second commit is to prevent CORS errors: when a file is linked from a file itself imported, the web browser considers they come from a different domain and therefore triggers the error. The option tells the web browser to ignore this case.
cc ```@jsha```
r? ```@notriddle```
Add QEMU test for x86_64-unknown-uefi
The UEFI targets don't have std support yet, so the normal tests don't work. However, we can compile a simple no-std program and run it under QEMU to at least check that the target compiles, links, and runs.
Tested locally with: `src/ci/docker/run.sh x86_64-uefi`
ci: Bring back ninja for dist builders
The primary reason for this is that make can result in a substantial under utilization of parallelism (noticed while testing on a workstation), mostly due to the submake structure preventing good dependency tracking and scheduling.
In f758c7b2a7 (Debian 6 doesn't have ninja, so use make for the dist builds) llvm.ninja was disabled due to lack of distro package. This is no longer the case with the CentOS 7 base, so bring ninja back for a performance boost.
This reverts commit 3acb505ee5
(PR #101833).
The changes in this commit caused several bugs or at least
incompatibilies. For now we're reverting this commit and will re-land it
alongside fixes for those bugs.
update Miri
I had to use a hacked version of josh to create this, so let's be careful with merging this and maybe wait a bit to see if the josh issue becomes more clear. But the history looks good to me, we are not adding duplicates of rustc commits that were previously mirrored to Miri.
Also I want to add some cross-testing of Miri in x.py.
Upgrade dist-mips*-linux to ubuntu:22.04 + crosstool-ng
These have no change in compatibility, still Linux 4.4 and glibc 2.23.
The main motivation for upgrading is that LLVM 16 will require at least GCC 7.1. Using crosstool-ng lets us choose our own toolchain versions, and then the Ubuntu version doesn't matter so much, just for the host compilation while we cross-compile.
The primary reason for this is that make can result in a substantial
under utilization of parallelism, mostly due to the submake structure
preventing good dependency tracking and scheduling.
In f758c7b2a7 (Debian 6 doesn't have ninja, so use make for the dist builds)
llvm.ninja was disabled due to lack of distro package. This is no longer the
case with the CentOS 7 base, so bring ninja back for a performance boost.
