Clarified error note for usize range matching
Fixesrust-lang/rust#146476
This is kinda rough, but it gets the point across a little better and stays short.
Include additional hashes in src/stage0
This patch changes `bump-stage0` to include:
* The sha256 hash of the channel manifest used to create `src/stage0`.
* The rust and rustfmt git commit in `src/stage0`.
* Hashes of all the artifacts, like the source tarball, in `src/stage0`.
Combined this will allow for:
* Projects that bootstrap their own compiler, such as Fuchsia, or users of [bootstrap], to build their compilers offline without needing to communicate with static.rust-lang.org.
* Auditors to detect if the channel manifest, and all the artifacts inside the manifest, were modified after it was used to generate `src/stage0`. Furthermore, if they did find modified artifacts, they could determine if the Rust Signing Key was compromised by checking if any modified file was signed properly.
finally, it allows regeneration of `src/stage0` when specifying both the day of the build for rust, and the day of the build for rustfmt, which can allow a maintainer to regenerate `src/stage0` to verify nothing changed.
[bootstrap]: https://github.com/dtolnay/bootstrap
[mrustc]: https://github.com/thepowersgang/mrustc
Remove most `#[track_caller]` from allocating Vec methods
They cause significant binary size overhead while contributing little value.
closesrust-lang/rust#146963, see that issue for more details.
Make it possible to `x install` Cranelift and LLVM bitcode linker
It was not possible to install these before, as they were not in the install step description list.
Fixes: https://github.com/rust-lang/rust/issues/140331
r? `@jieyouxu`
Make `def_path_hash_to_def_id` not panic when passed an invalid hash
I'm using this function in a third-party application (Creusot) to access private items (by reverse engineering their hash). This works in the happy path, but it panics when an item does not exist. There is no way to hack it downstream because the hook `def_path_hash_to_def_id_extern` must always return a `DefId` and its implementation uses `def_path_hash_to_def_index` which is internal and which is where the panic happens.
Rename `rust.use-lld` to `rust.bootstrap-override-lld`
First part of https://github.com/rust-lang/rust/issues/146640. The old option is kept for backwards compatibility, we can remove it in ~6 months, as usually.
I'm not sure if the bootstrap prefix is ideal, after all we have a bunch of other configs that only affect bootstrap's behavior and not the built artifacts. Maybe `build.override-lld`? But I don't think it matters that much, as long as it's clear that it is an override, and how does it differ from `rust.lld`.
r? ``@jieyouxu``
Fix doctest compilation time display
Fixesrust-lang/rust#146960.
Small corner case that happened in case everything went fine and there was only merged doctests.
r? lolbinarycat
re-order normalizations in run-make linker-warning test
otherwise a buildroot containing `rustc[^/_-]*` or `libpanic_abort` would be mangled before being replaced by the build root placeholder value..
e.g., running `./x.py test --verbose tests/run-make/linker-warning` with rustc checked out in ~/ext/rustcfoobar will result in
```
running 1 tests
test [run-make] tests/run-make/linker-warning ... FAILED
failures:
---- [run-make] tests/run-make/linker-warning stdout ----
------rustc stdout------------------------------
------rustc stderr------------------------------
------------------------------------------
error: rmake recipe failed to complete
status: exit status: 101
command: cd "/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/test/run-make/linker-warning/rmake_out" && env -u RUSTFLAGS -u __RUSTC_DEBUG_ASSERTIONS_ENABLED -u __STD_DEBUG_ASSERTIONS_ENABLED AR="ar" BUILD_ROOT="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu" CC="cc" CC_DEFAULT_FLAGS="-ffunction-sections -fdata-sections -fPIC -m64" CXX="c++" CXX_DEFAULT_FLAGS="-ffunction-sections -fdata-sections -fPIC -m64" HOST_RUSTC_DYLIB_PATH="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/stage1/lib" LD_LIBRARY_PATH="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib" LD_LIB_PATH_ENVVAR="LD_LIBRARY_PATH" LLVM_BIN_DIR="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/ci-llvm/bin" LLVM_COMPONENTS="<..>" LLVM_FILECHECK="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" NODE="/usr/bin/node" PYTHON="/usr/bin/python3" RUSTC="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" RUSTDOC="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/stage1/bin/rustdoc" SOURCE_ROOT="/home/user/ext/rustcfoobar" TARGET="x86_64-unknown-linux-gnu" TARGET_EXE_DYLIB_PATH="/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/user/ext/rustcfoobar/build/x86_64-unknown-linux-gnu/test/run-make/linker-warning/rmake"
stdout: none
--- stderr -------------------------------
thread 'main' panicked at /home/user/ext/rustcfoobar/tests/run-make/linker-warning/rmake.rs:74:14:
test failed: `short-error.txt` is different from `(linker error)`
--- short-error.txt
+++ (linker error)
``@@`` -1,6 +1,6 ``@@``
error: linking with `./fake-linker` failed: exit status: 1
|
- = note: "./fake-linker" "-m64" "/symbols.o" "<2 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "/build-root/test/run-make/linker-warning/rmake_out/{libfoo,libbar}.rlib" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/{libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/build-root/test/run-make/linker-warning/rmake_out" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "main" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "run_make_error"
+ = note: "./fake-linker" "-m64" "/symbols.o" "<2 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "/home/user/ext/rustc/build/x86_64-unknown-linux-gnu/test/run-make/linker-warning/rmake_out/{libfoo,libbar}.rlib" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/{libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/user/ext/rustc/build/x86_64-unknown-linux-gnu/test/run-make/linker-warning/rmake_out" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "main" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "run_make_error"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: error: baz
[..]
```
without this fix.
Note: this affected Debian's automated builds, since the buildroot contains the package name and version. while that particular issue got fixed in the meantime by accident by making the RE more strict in 77232fb935 , other buildroot paths are still affected without a full fix.
tests: relax expectations after llvm change 902ddda120a5
LLVM 22 is able to drop assumes that seem to not help further optimizations, which actually seems to dramatically _help_ further optimizations in some of our small test cases.
I'm a little unclear how to fix the last failure, in `tests/codegen-llvm/issues/issue-122600-ptr-discriminant-update.rs`:
```
-; Function Attrs: mustprogress nofree norecurse nosync nounwind willreturn memory(argmem: readwrite, inaccessiblemem: write) uwtable
+; Function Attrs: mustprogress nofree norecurse nosync nounwind nonlazybind willreturn memory(argmem: readwrite, inaccessiblemem: write) uwtable
define void ``@update(ptr`` noundef captures(none) %s) unnamed_addr #0 {
start:
- %_3.sroa.0.0.copyload = load i8, ptr %s, align 1
- %0 = trunc nuw i8 %_3.sroa.0.0.copyload to i1
- %1 = xor i1 %0, true
- tail call void ``@llvm.assume(i1`` %1)
store i8 1, ptr %s, align 1
ret void
}
```
I'm just not conversant enough in LLVM IR to follow the changes here.
``@rustbot`` label llvm-main
r? nikic
Introduce CoerceShared lang item and trait, and basic Reborrow tests
Part of rust-lang/rust#145612: This introduces the `CoerceShared` trait which is the `Reborrow` equivalent of a `&mut T` -> `&T` coercion. The trait has a `Target` GAT which makes this (currently) unique in the `core/src/marker.rs`; I'm not sure if this can be considered problematic. Maybe this is not the way such things should be done at the marker trait level? Or maybe it is fine.
Improtantly, this PR introduces a battery of basic `Reborrow` and `CoerceShared` tests. These test the very basics of the feature; custom marker types intended to have exclusive semantics (`Custom<'a>(PhantomData<&'a mut ()>)`), custom exclusive reference wrappers, and standard library exclusive reference wrappers (`Pin<&mut T>` and `Option<&mut T>`). None of these of course work since the implementation for `Reborrow` and `CoerceShared` is entirely missing, but this is the first step towards making these work.
Future PRs will introduce more tests, such as "recursive" reborrowing (ie. reborrowing structs that contain multiple reborrowable fields) and checks around the lifetime semantics of reborrowing ie. that a reborrow produces a new type with the same lifetime as the original.
Implement RFC 3631: add rustdoc doc_cfg features
Implementation of https://github.com/rust-lang/rfcs/pull/3631.
This implementation actually resulted in a lot of simplifications:
* All `cfg` computation is now done in one place: `propagate_doc_cfg.rs`. Because (trait) `impl`s are not retrieved at the same time as the other items, we cannot perform this computation in the clean process, it needs to be after.
* Because there is `cfg` inheritance, we can keep track of them in one place (in `propagate_doc_cfg.rs`), meaning we don't need to copy an item's attributes to its children anymore. Only exception: impl items. For them we clone only `cfg` attributes.
* `propagate_doc_cfg.rs` is also now much simpler, much less need to keep track of parents, since everything we need is handled by the new `CfgInfo` type.
* I also suspect that `Cfg::simplify_with` could either be removed or at least used directly into `propagate_doc_cfg.rs` when we compute `cfg`s. Considering how big the PR already is, I'll do it in a follow-up.
I didn't remove the `doc_cfg*` features in this PR because some dependencies used in `rustc` (like `stdarch`) are using it, so we need to have a nightly released with this PR before I can switch to the new feature.
r? ghost
This patch changes `bump-stage0` to include:
* The sha256 hash of the channel manifest used to create `src/stage0`.
* The rust and rustfmt git commit in `src/stage0`.
* Hashes of all the artifacts, like the source tarball, in `src/stage0`.
Combined this will allow for:
* Projects that bootstrap their own compiler, such as Fuchsia, or users
of [bootstrap], to build their compilers offline without needing to
communicate with static.rust-lang.org.
* Auditors to detect if the channel manifest, and all the artifacts
inside the manifest, were modified after it was used to generate
`src/stage0`. Furthermore, if they did find modified artifacts, they
could determine if the Rust Signing Key was compromised by checking if
any modified file was signed properly.
Finally, it allows regeneration of `src/stage0` when specifying both the
day of the build for rust, and the day of the build for rustfmt, which
can allow a maintainer to regenerate `src/stage0` to verify nothing
changed.
[bootstrap]: https://github.com/dtolnay/bootstrap
[mrustc]: https://github.com/thepowersgang/mrustc
JumpThreading: Avoid computing dominators to identify loop headers.
JumpThreading tries to avoid threading through loop headers to avoid creating irreducible CFGs.
However, computing dominators is expensive, and accounts up to 20 % of the runtime of the JumpThreading pass for some cases like serde.
This PR proposes to approximate according to the post-order traversal order. We define a "maybe" loop header as a block which is visited after its predecessor in post-order.
