"stage 1" for fulldeps means "compile with stage 0, link against stage 1".
But this code wanted to switch on the compiler that's building, not the
compiler that's being tested. Fix the check.
Previously, it would fail with a warning about linker-messages:
```
--- stderr -------------------------------
warning[E0602]: unknown lint: `linker_messages`
|
= note: requested on the command line with `-A linker_messages`
= note: `#[warn(unknown_lints)]` on by default
```
Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle
This PR should not be merged until the rustc_codegen_llvm part is merged.
I will also alter it a little based on what get's shaved off from the cg_llvm PR,
and address some of the feedback I received in the other PR (including cleanups).
I am putting it already up to
1) Discuss with `@jieyouxu` if there is more work needed to add tests to this and
2) Pray that there is someone reviewing who can tell me why some of my autodiff invocations get lost.
Re 1: My test require fat-lto. I also modify the compilation pipeline. So if there are any other llvm-ir tests in the same compilation unit then I will likely break them. Luckily there are two groups who currently have the same fat-lto requirement for their GPU code which I have for my autodiff code and both groups have some plans to enable support for thin-lto. Once either that work pans out, I'll copy it over for this feature. I will also work on not changing the optimization pipeline for functions not differentiated, but that will require some thoughts and engineering, so I think it would be good to be able to run the autodiff tests isolated from the rest for now. Can you guide me here please?
For context, here are some of my tests in the samples folder: https://github.com/EnzymeAD/rustbook
Re 2: This is a pretty serious issue, since it effectively prevents publishing libraries making use of autodiff: https://github.com/EnzymeAD/rust/issues/173. For some reason my dummy code persists till the end, so the code which calls autodiff, deletes the dummy, and inserts the code to compute the derivative never gets executed. To me it looks like the rustc_autodiff attribute just get's dropped, but I don't know WHY? Any help would be super appreciated, as rustc queries look a bit voodoo to me.
Tracking:
- https://github.com/rust-lang/rust/issues/124509
r? `@jieyouxu`
override build profile for bootstrap tests
Using the release profile for bootstrap self tests puts too much load on the CPU and makes it quite hot on `x test bootstrap` invocation for no good reason. It also makes the compilation take longer than usual (see https://github.com/rust-lang/rust/pull/136048#issuecomment-2616908484). This change turns off the release flag for bootstrap self tests.
Apply LTO config to rustdoc
Before, the LTO configuration from `config.toml` was not applied to `rustdoc`. This provides a small perf. and binary size [win](https://github.com/rust-lang/rust/pull/112049#issuecomment-2605131041) for doc builds.
Since this is configured with Cargo profiles and not rustflags, it should not break tool build cache (https://github.com/rust-lang/rust/pull/131155). I tried to run `x test miri`, `x test rustdoc` and `x test miri` and nothing was rebuilt.
r? `@onur-ozkan`
Put the core unit tests in a separate coretests package
Having standard library tests in the same package as a standard library crate has bad side effects. It causes the test to have a dependency on a locally built standard library crate, while also indirectly depending on it through libtest. Currently this works out fine in the context of rust's build system as both copies are identical, but for example in cg_clif's tests I've found it basically impossible to compile both copies with the exact same compiler flags and thus the two copies would cause lang item conflicts.
This PR moves the tests of libcore to a separate package which doesn't depend on libcore, thus preventing the duplicate crates even when compiler flags don't exactly match between building the sysroot (for libtest) and building the test itself. The rest of the standard library crates do still have this issue however.
Support QNX 7.1 with `io-sock`+libstd and QNX 8.0 (`no_std` only)
Changes of this pull request:
1. Refactor code for qnx nto targets to share more code in file `nto_qnx.rs`
1. Add support for an additional network stack on nto qnx 7.1.
QNX 7.1 supports two network stacks:
1. `io-pkt`, which is default
2. `io-sock`, which is optional on 7.1 but default in QNX 8.0
As one can see in the [io-sock migration notes](https://www.qnx.com/developers/docs/7.1/index.html#com.qnx.doc.neutrino.io_sock/topic/migrate_app.html), this changes the libc API in a way similar to e.g. linux-gnu vs. linux-musl.
This change adds a new target which has a different value for `target_env`, so that e.g. libc can distinguish between both APIs.
2. Add initial support for QNX 8.0, thanks to AkhilTThomas. As it turned out, the problem with forking many processes still exists in QNX 8.0. Because if this, we are now using it for any QNX version (i.e. not check for `target_env` anymore).
Bootstrap: Don't move ownership of job object
I've been thinking about this since the last time I looked at bootstrap's use of job objects. We currently pass ownership of the job object to Python. I feel this is unneeded complexity.
The rationale given (in a comment) is that it helps with `ctrl-c` on `x.py`. But using `ctrl-c` when running `x.py` will also cause `bootstrap.exe` to immediately exit so I don't find that convincing.
ld is showing things like this:
```
ld: ignoring duplicate libraries: '-lm'
```
I don't have time or a macbook that lets me investigate these. Just silence them for now.
Make it possible to build GCC on CI
This is the first step towards eventually enabling download of precompiled GCC from our CI.
Currently, we prebuild `libgccjit` on CI and cache it in Docker. This PR improves the bootstrap GCC step to make it work on CI, and also to make it faster by using sccache. After this change, an actual build on CI should take only 2-3 minutes.
Note that this PR does not yet remove the `build-gccjit.sh` script and replace it with the bootstrap step, I'll leave that to a follow-up PR.
The added `flex` package and the ZSTD library fix were needed to make GCC build on CI.
CC ``````@GuillaumeGomez``````
r? ``````@onur-ozkan``````
Do not include GCC source code in source tarballs
The licensing story is unclear, it makes the archive much larger, and we should not need it for building anything in the tarballs (yet).
```
Before:
121s building the archive
1.3 GiB gzipped size
5.7 GiB extracted size
402519 extracted files
After:
64s building the archive
961 MiB gzipped size
4.5 GiB extracted size
257719 extracfed files
```
Fixes: https://github.com/rust-lang/rust/issues/135606
r? `@ehuss`
Add Profile Override for Non-Git Sources
## PR description
- Fixes#135358
This PR introduces the following updates to
1. `bootstrap.py`:
- If the `profile` is `None` and the source is non-git, the `profile` is automatically overridden to `"dist"`.
- Ensures that options like `download-ci-llvm` and `download-rustc` are not used with non-git sources. An exception is raised if these options are present in the configuration when the source is non-git.
2. `bootstrap_test.py`
- Added unit tests to verify both the profile override mechanism and the assertion for restricted options.
These tests ensure the correct behavior for non-git sources and the handling of `if-unchanged` options.
r? `@onur-ozkan`
`@rustbot` T-bootstrap
make it possible to use ci-rustc on tarball sources
Previously, bootstrap was using `Config::last_modified_commit` unconditionally to figure the commit to download precompiled rustc artifact from CI, which was leading builds to fail on tarball sources as `Config::last_modified_commit` requires `git` to be present in the project source. This change makes bootstrap to call `Config::last_modified_commit` only when it's running on git-managed source and read `git-commit-hash` file otherwise.
Previously, bootstrap was using `Config::last_modified_commit` unconditionally to figure
the commit has to download precompiled rustc artifact from CI, which was leading builds to
fail on tarball sources as `Config::last_modified_commit` requires `git` to be present in the project
source. This change makes bootstrap to call `Config::last_modified_commit` only when it's running on
git-managed source and read `git-commit-hash` file otherwise.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Rollup of 7 pull requests
Successful merges:
- #133700 (const-eval: detect more pointers as definitely not-null)
- #135290 (Encode constraints that hold at all points as logical edges in location-sensitive polonius)
- #135478 (Run clippy for rustc_codegen_gcc on CI)
- #135583 (Move `std::pipe::*` into `std::io`)
- #135612 (Include x scripts in tarballs)
- #135624 (ci: mirror buildkit image to ghcr)
- #135661 (Stabilize `float_next_up_down`)
r? `@ghost`
`@rustbot` modify labels: rollup
