| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This reverts commit 6efacfb7a59ebde2620398861713fae136060a04.
|
|
|
|
|
|
do not build additional stage on compiler paths
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler, which is clearly not what we requested. This doesn't happen when running `x build --stage N` without explicitly targeting the compiler.
The changes applied fix this issue.
r? ghost
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
When calling `x build compiler (or rustc) --stage N` bootstrap builds stage N+1 compiler,
which is clearly not what we requested. This doesn't happen when running `x build --stage N`
without explicitly targeting the compiler.
The changes applied fix this issue.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #134943 (Add FileCheck annotations to mir-opt/issues)
- #137017 (Don't error when adding a staticlib with bitcode files compiled by newer LLVM)
- #137197 (Update some comparison codegen tests now that they pass in LLVM20)
- #137540 (Fix (more) test directives that were accidentally ignored)
- #137551 (import `simd_` intrinsics)
- #137599 (tests: use minicore more)
- #137673 (Fix Windows `Command` search path bug)
- #137676 (linker: Fix escaping style for response files on Windows)
- #137693 (Re-enable `--generate-link-to-defintion` for tools internal rustdoc)
- #137770 (Fix sized constraint for unsafe binder)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
Re-enable `--generate-link-to-defintion` for tools internal rustdoc
~~These were removed because they used to break the build: https://github.com/rust-lang/rust/pull/122066#issuecomment-1983049222, but testing locally it seems to work now.~~
This was re enabled in #136589, but only for rustc, not tools.
The FIXME that prompted removing this is still present. Do we have an issue with an MCVE for this? CC ```@GuillaumeGomez```
https://github.com/rust-lang/rust/blob/ac91805f3179fc2225c60e8ccf5a1daa09d43f3d/src/librustdoc/html/render/span_map.rs#L178-L182
try-job: aarch64-apple
|
|
linker: Fix escaping style for response files on Windows
If we use a С/С++ compiler as linker, then Posix-style escaping should be used.
Also temporarily fixup rustbuild to not fail at least in common scenarios, until the bootstrap compiler is updated.
Fixes https://github.com/rust-lang/rust/issues/137498
|
|
|
|
To distribute the prebuilt libgccjit.so from CI.
|
|
[`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing
Reference for overall changes: https://github.com/rust-lang/rust/pull/136437
Part **4** of **7** of the *`compiletest`-related cleanups* PR series.
### Summary
- Remove `--build-base` compiletest flag, and introduce `--build-{root,test-suite-root}` flags instead. `--build-base` previously actually is test suite specific build directory, not the root `build/` directory.
- Feed the root build directory directly from bootstrap to compiletest via `--build-root` instead of doing multiple layers of parent unwrapping[^parent] based on the test suite specific build directory.
- Remove a redundant `to_path_buf()`.
[^parent]: Please do not unwrap the parents.
r? bootstrap
|
|
fixed wast version was released, remove randomization exemption
|
|
|
|
It is reasonable to expect that ./x.py test core is enough to run tests
when you are working on core. In addition it seems like CI for wasm32 at
least doesn't run coretests currently, which this commit fixes.
|
|
This overrides the test=false flag in Cargo.toml and it shouldn't be
necessary as --tests is already passed.
|
|
If we use a С/С++ compiler as linker, then Posix-style escaping should be used.
|
|
Include version number of libs being built in cargo lib metadata (esp. `librustc_driver*.so`)
Previously, on a non-stable channel, it's possible for two builds from different versioned sources (e.g. 1.84.0 vs 1.84.1) to produce a `librustc_driver*.so` with the same filename hashes. This causes problems with side-by-side installs wrt. linker search paths because 1.84.1 rustc bin and 1.84.0 rustc bin may try to link to the "same" `librustc_driver*.so` (same filename hash) but fail because the contents of the so is actually different.
We try to mitigate this by including the version number of artifacts being built via `__CARGO_DEFAULT_LIB_METADATA` (kind of an ugly hack, but I don't think cargo has a way for us to tell cargo to use a package version override).
Fixes #136701 (mitigates, really).
### Testing
Tested manually[^host] by:
```bash
$ cat src/version
1.86.0
$ ./x build library # w/ compiler profile, (non-stable) dev channel
$ lddtree build/host/stage1/bin/rustc
rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2)
librustc_driver-ea1b1b2291881cc4.so => build/host/stage1/bin/../lib/librustc_driver-ea1b1b2291881cc4.so
[...]
```
and observing that changing `src/version` to bump a point release causes `librustc_driver*.so` to have a different hash while sources are unmodified otherwise.
```bash
$ cat src/version
1.86.1
$ ./x build library # w/ compiler profile, (non-stable) dev channel
$ lddtree build/host/stage1/bin/rustc
rustc => build/host/stage1/bin/rustc (interpreter => /lib64/ld-linux-x86-64.so.2)
librustc_driver-746badadbcb74721.so => build/host/stage1/bin/../lib/librustc_driver-746badadbcb74721.so
[...]
```
cc `@clan` `@demize` could you check that if you backport this change against 1.84.{0,1} as reported in #136701, that the produced `rustc` binary works, under the context of the Gentoo build system setup?
[^host]: on a `x86_64-unknown-linux-gnu` host, no cross
|
|
Build GCC on CI
Previously, we have downloaded a specific commit of GCC and prebuilt it inside Docker using the `build-gccjit.sh` script. This PR removes that scripts and uses the bootstrap GCC step. This allows us to use the `src/gcc` submodule for determining which GCC should be built, and it also moves the logic closer to LLVM, which is also built by bootstrap.
A few things to note:
- The `sccache` option is currently in the `llvm` block, so the GCC build uses `llvm.ccache`, which is a bit weird :) We could either add `gcc.ccache`, or (what I think would be better) to just move `ccache` to the `build` section, as I don't think that it will be necessary to use ccache for LLVM, but not for GCC.
- When the GCC codegen backend is built, it needs to depend on a step that first builds GCC. This is currently done in a hacky way. The proper solution is to create a separate step for the GCC codegen backend, but that is a larger change. Let me know what you think.
r? `@onur-ozkan`
try-job: i686-msvc-1
try-job: x86_64-mingw-1
|
|
use stage 2 on cargo and clippy tests when possible
Follow-up for #137215.
For more context, read the discussion starting from https://github.com/rust-lang/rust/pull/137215#issuecomment-2674395959.
r? Kobzol (Feel free to re-r if you are not available).
|
|
downgrade bootstrap `cc`
Current `cc` version causing bootstrap to fail on custom targets. See https://github.com/rust-lang/cc-rs/issues/1317 for more context.
Fixes (after beta and stable backports): https://github.com/rust-lang/rust/issues/137064 and https://github.com/rust-lang/rust/issues/135271
|
|
configure.py: don't instruct user to run nonexistent program
```shell-session
$ ./configure
configure: processing command line
configure:
configure: build.configure-args := []
configure: profile := dist
configure:
configure: writing `config.toml` in current directory
configure:
configure: run `python /mnt/filling/store/nabijaczleweli/code/rust/x.py --help`
```
This is naturally not valid since I don't have a "python" executable (and this will hopefully become more and more true as Python 2 dies out).
./configure knows this since it does `try python3 "$``@"`,`` then `python2.7` &c.
After, this now says
```
configure: run `python3 /mnt/filling/store/nabijaczleweli/code/rust/x.py --help`
```
which is possible, and corresponds to the interpreter actually running.
|
|
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>
|
|
Rollup of 8 pull requests
Successful merges:
- #136439 (Misc. `rustc_codegen_ssa` cleanups 🧹)
- #136543 (intrinsics: unify rint, roundeven, nearbyint in a single round_ties_even intrinsic)
- #136637 (Add binary_format to rustc target specs)
- #137099 (Fix rustdoc test directives that were accidentally ignored 🧐)
- #137297 (Update `compiler-builtins` to 0.1.147)
- #137451 (FIx `sym` -> `syn` typo in tail-expr-drop-order type opt-out)
- #137452 (bootstrap: add module docs for core:metadata)
- #137483 (rename sub_ptr to offset_from_unsigned)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
avoid `compiler_for` for dist tools and force the current compiler
Using `compiler_for` in dist steps was causing to install stage1 tools into the dist tarballs, which doesn't match with the stage2 compiler.
Fixes https://github.com/rust-lang/rust/issues/137469
|
|
Shourya742:2025-02-23-add-module-level-doc-for-core-metadata, r=Kobzol
bootstrap: add module docs for core:metadata
Add module doc for bootstrap:core:metadata
|
|
$ ./configure
configure: processing command line
configure:
configure: build.configure-args := []
configure: profile := dist
configure:
configure: writing `config.toml` in current directory
configure:
configure: run `python /mnt/filling/store/nabijaczleweli/code/rust/x.py --help`
This is naturally not valid since I don't have a "python" executable
(and this will hopefully become more and more true as Python 2 dies out).
./configure knows this since it does try python3 "$@", then python2.7 &c.
After, this now says
configure: run `python3 /mnt/filling/store/nabijaczleweli/code/rust/x.py --help`
which is possible, and corresponds to the interpreter actually running.
|
|
|
|
`--build-test-suite-root` instead
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Master bootstrap update
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday
r? `@Mark-Simulacrum`
|
|
Rollup of 9 pull requests
Successful merges:
- #135354 ([Debuginfo] Add MSVC Synthetic and Summary providers to LLDB)
- #136826 (Replace mem::zeroed with mem::MaybeUninit::uninit for large struct in Unix)
- #137194 (More const {} init in thread_local)
- #137334 (Greatly simplify lifetime captures in edition 2024)
- #137382 (bootstrap: add doc for vendor build step)
- #137423 (Improve a bit HIR pretty printer)
- #137435 (Fix "missing match arm body" suggestion involving `!`)
- #137448 (Fix bugs due to unhandled `ControlFlow` in compiler)
- #137458 (Fix missing self subst when rendering `impl Fn*<T>` with no output type)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
bootstrap: add doc for vendor build step
This PR adds docs for vendor build step.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
stabilize stage management for rustc tools
https://github.com/rust-lang/rust/pull/135990 got out of control due to excessive complexity. This PR aims to achieve the same goal with a simpler approach, likely through multiple smaller PRs. I will keep the other one read-only and open as a reference for future work.
This work stabilizes the staging logic for `ToolRustc` programs, so you no longer need to handle build and target compilers separately in steps. Previously, most tools didn't do this correctly, which was causing the compiler to be built twice (e.g., `x test cargo --stage 1` would compile the stage 2 compiler before, but now it only compiles the stage 1 compiler).
I also tried to document how we should write `ToolRustc` steps as they are quite different and require more attention than other tools.
Next goal is to stabilize how stages are handled for the rustc itself. Currently, `x build --stage 1` builds the stage 1 compiler which is fine, but `x build compiler --stage 1` builds stage 2 compiler.
~~for now, r? ghost~~
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #136910 (Implement feature `isolate_most_least_significant_one` for integer types)
- #137183 (Prune dead regionck code)
- #137333 (Use `edition = "2024"` in the compiler (redux))
- #137356 (Ferris 🦀 Identifier naming conventions)
- #137362 (Add build step log for `run-make-support`)
- #137377 (Always allow reusing cratenum in CrateLoader::load)
- #137388 (Fix(lib/fs/tests): Disable rename POSIX semantics FS tests under Windows 7)
- #137410 (Use StableHasher + Hash64 for dep_tracking_hash)
- #137413 (jubilee cleared out the review queue)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add build step log for `run-make-support`
I was always confused about what is being built, since nothing was printed in the log :)
r? ``@jieyouxu``
|
|
test building enzyme in CI
1) This PR fixes a significant compile-time regression, by only running the expensive autodiff pipeline, if the users pass the newly introduced Enable value to the `-Zautodiff=` flag. It updates the test(s) accordingly. It gives a nice error if users forget that.
2) It fixes macos support by explicitly linking against the Enzyme build folder. This doesn't cover CI macos yet.
3) It fixes the issue that setting ENZYME_RUNPASS was ignored by enzyme and in fact did not schedule enzyme's opt pass.
4) It also re-enables support for various other values for the autodiff flag, which were ignored since the refactor.
5) I merged some improvements to Enzyme core, which means we do not longer depend on LLVM being build with the Plugin Interface enabled.
6) Unrelated to other fixes, this changes `rustc_autodiff` to `EncodeCrossCrate::Yes`. It is not enough on it's own to enable usage of Enzyme in libraries, but it is for sure a piece of the fixes needed to get this to work.
try-job: x86_64-gnu
r? `@oli-obk`
Tracking:
- https://github.com/rust-lang/rust/issues/124509
|
