| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
bump download-ci-llvm-stamp
This should trigger the download and extraction of the ci-llvm tarball, which should resolve https://github.com/rust-lang/rust/issues/130144.
|
|
use `download-ci-llvm=true` in the default compiler config
https://github.com/rust-lang/rust/commit/1ca2708e77ac735adc3824501667694b4f9c1303 made it so that the `src/llvm-project` submodule has to be checkout for `download-ci-llvm = "if-unchanged"` to know if the submodule has been changed, but that is not required, if the submodule hasn't been checkout it cannot have been modified.
~~This PR restore the previous behavior by only updating the submodule if it has already been checkout.~~
This PR makes `download-ci-llvm = true` check if CI llvm is available and make it the default for the compiler profile, as to prevent unnecessarily checking out `src/llvm-project` with `"if-unchanged"`.
r? `````@onur-ozkan`````
|
|
Rollup of 9 pull requests
Successful merges:
- #129929 (`rustc_mir_transform` cleanups, round 2)
- #130022 (Dataflow/borrowck lifetime cleanups)
- #130064 (fix ICE in CMSE type validation)
- #130067 (Remove redundant check in `symlink_hard_link` test)
- #130131 (Print a helpful message if any tests were skipped for being up-to-date)
- #130137 (Fix ICE caused by missing span in a region error)
- #130153 (use verbose flag as a default value for `rust.verbose-tests`)
- #130154 (Stabilize `char::MIN`)
- #130158 (Update books)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
use verbose flag as a default value for `rust.verbose-tests`
See the [Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Run.20tests.20in.20x.2Epy.20with.20.22pretty.22.20test.20rendering.3F) for more context.
|
|
Print a helpful message if any tests were skipped for being up-to-date
When running tests without the `--force-rerun` flag, compiletest will automatically skip any tests that (in its judgement) don't need to be run again since the last time they were run.
This is normally very useful, but can occasionally be confusing, especially in edge-cases where up-to-date checking is not completely accurate (or the test is flaky).
This PR makes bootstrap count the number of tests that were ignored for being up-to-date (via a hard-coded check on the ignore reason), and prints a helpful message when that number is nonzero.
---
Sample output:
```text
test result: ok. 4 passed; 0 failed; 17578 ignored; 0 measured; 0 filtered out; finished in 463.79ms
help: ignored 17295 up-to-date tests; use `--force-rerun` to prevent this
Build completed successfully in 0:00:07
```
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Distribute rustc_codegen_cranelift for Windows
With support for raw-dylib recently added to cg_clif, and inline assembly support working on Windows for quite a while now, all blockers for distributing cg_clif on Windows that I mentioned in https://github.com/rust-lang/rust/pull/81746#issuecomment-1774099637 are fixed now.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Do not skip linker configuration for `check` builds
This essentially reverts a part of https://github.com/rust-lang/rust/pull/128871, to fix https://github.com/rust-lang/rust/issues/130108. This is mostly a hotfix until we can figure out a better way to both avoid rebuilds and avoid configuring the linker for `x check`.
Skipping linker for check builds was causing unexpected rebuilds.
Fixes: https://github.com/rust-lang/rust/issues/130108
|
|
also don't unnecessarily set BOOTSTRAP_SKIP_TARGET_SANITY while we are at it
|
|
Rollup of 14 pull requests
Successful merges:
- #119229 (Update mingw-w64 + GNU toolchain)
- #128345 (added support for GNU/Hurd on x86_64)
- #128667 (rustdoc: normalise type/field names)
- #129876 (Use sysroot crates maximally in `rustc_codegen_gcc`.)
- #130034 ( Fix enabling wasm-component-ld to match other tools )
- #130048 (run-make-support: Add llvm-pdbutil)
- #130068 (Test codegen when setting deployment target)
- #130070 (Rename variant `AddrOfRegion` of `RegionVariableOrigin` to `BorrowRegion`)
- #130087 (remove 'const' from 'Option::iter')
- #130090 (make Result::copied unstably const)
- #130092 (Fixes typo in wasm32-wasip2 doc comment)
- #130107 (const: make ptr.is_null() stop execution on ambiguity)
- #130115 (Remove needless returns detected by clippy in libraries)
- #130130 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
It was causing unexpected rebuilds.
|
|
r=onur-ozkan
Fix enabling wasm-component-ld to match other tools
It was [pointed out recently][comment] that enabling `wasm-component-ld` as a host tool is different from other host tools. This commit refactors the logic to match by deduplicating selection of when to build other tools and then using the same logic for `wasm-component-ld`.
While here I also fixed a typo pointed out in https://github.com/rust-lang/rust/pull/126967#pullrequestreview-2285267534
[comment]: https://github.com/rust-lang/rust/pull/127866#issuecomment-2333434720
|
|
|
|
fixes #130111
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Previously, the logic here was simply checking whether the option was set in `config.toml`.
This approach was not manageable in our CI runners as we set so many options in config.toml.
In reality, those values are not incompatible since they are usually the same value used to generate
the CI llvm. Now, the new logic compares the configuration values with the values used to generate
the CI llvm, so we get more precise results and make the process more manageable.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Remove the unused `llvm-skip-rebuild` option from x.py
Fixes #130039
|
|
explain the options bootstrap passes to curl
also fixes a discrepancy where the rust side doesn't use -L
docs are only on the rust side, since duplicated prose has a tendancy to get out-of-sync, and also because there are talks of removing the python script all together eventually.
|
|
bypass linker configuration and cross target check for specific commands
Avoids configuring the linker and checking cross-target-specific tools unless necessary.
Resolves #128180
cc `@ChrisDenton`
|
|
|
|
It was [pointed out recently][comment] that enabling `wasm-component-ld`
as a host tool is different from other host tools. This commit refactors
the logic to match by deduplicating selection of when to build other
tools and then using the same logic for `wasm-component-ld`.
[comment]: https://github.com/rust-lang/rust/pull/127866#issuecomment-2333434720
|
|
and make it the default for the compiler profile, as to prevent
unnecessarily checking out `src/llvm-project` with `"if-unchanged"`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Autodiff Upstreaming - enzyme backend
Tracking issue: https://github.com/rust-lang/rust/issues/124509
Part of https://github.com/rust-lang/rust/pull/129175
This PR should allow building Enzyme from source on Tier 1 targets (when also building LLVM), except MSVC.
It's only a small fraction (~200 lines) of the whole upstream PR, but due to bootstrapping and the number of configurations in which rustc can be build I assume that this will be the hardest to merge, so I'm starting with it.
Happy to hear what changes are required to be able to upstream this code.
**Content:**
It contains a new configure flag `--enable-llvm-enzyme`, and will build the new Enzyme submodule when it is set.
**Discussion:**
Apparently Rust CI isn't able to clone repositories outside the rust-lang org? At least I'm seeing this error in CI:
```
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
```
Does that mean we would need to mirror github.com/EnzymeAD/Enzyme in rust-lang, until LLVM upgrades Enzyme from an Incubator project to something that ships as part of the monorepo?
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
|
Make `./x.py <cmd> compiler/<crate>` aware of the crate's features
Does not fix https://github.com/rust-lang/rust/issues/129727 on its own as the way the parallel-compiler cfg and feature flags are setup being generally incompatible with `resolver = 2` but it progresses on the issue. But this should in theory allow compiler crates to work that do not depend on the parallel compiler stuff (so some leaf crates).
|
|
Co-authored-by: Lorenz Schmidt <bytesnake@mailbox.org>
|
|
|
|
forward linker option to lint-docs
This fixes an error found when building the doc for a cross-built toolchain.
```
warning: the code example in lint `unstable_syntax_pre_expansion` in /buildroots/chenx97/rustc-1.80.1-src/compiler/rustc_lint_defs/src/builtin.rs failed to generate the expected output: did not find lint `unstable_syntax_p
re_expansion` in output of example, got:
error: linking with `cc` failed: exit status: 1
...
```
Closes: #129956
|
|
use the bootstrapped compiler for `test-float-parse` test
Fixes https://github.com/rust-lang/rust/pull/122709#issuecomment-2327259336.
Blocker for https://github.com/rust-lang/rust/pull/122709
|
|
copy rustc rustlib artifacts from ci-rustc
We recently (since https://github.com/rust-lang/rust/pull/129311) had an issue because some rustlib files were missing (like: "error[E0463]: can't find crate for rustc_ast") when building tools that rely on rustc. This patch fixes that by copying those files as required.
r? Kobzol
Blocker for https://github.com/rust-lang/rust/pull/122709
|
|
bootstrap: Try to track down why `initial_libdir` sometimes fails
When I try to run `x` commands from the command-line, I occasionally see a mysterious failure that looks something like this:
```text
thread 'main' panicked at src/lib.rs:341:14:
called `Result::unwrap()` on an `Err` value: StripPrefixError(())
```
It happens often enough to be annoying, but rarely enough that I can't reproduce it at will. The error message points to a particular `unwrap` call, but doesn't include enough context to determine *why* the failure occurs.
Re-running the command almost always works, so I suspect some kind of filesystem race condition (possibly involving VSCode invoking bootstrap at the same time), but there's not much I can do with the information I currently have.
So this PR includes some relevant information in the panic message when the failure occurs, in the hope that doing so will make the cause easier to track down when the failure occurs again.
|
