bootstrap: fix bug preventing the use of custom targets
the bug was caused by two factors:
1. only checking the RUST_TARGET_PATH form, not the full filepath form
2. indirectly trying to use the Debug presentation to get the file path
Revert recent changes to dead code analysis
This is a revert to recent changes to dead code analysis, namely:
* efdf219 Rollup merge of #128104 - mu001999-contrib:fix/128053, r=petrochenkov
* a70dc297a8 Rollup merge of #127017 - mu001999-contrib:dead/enhance, r=pnkfelix
* 31fe9628cf Rollup merge of #127107 - mu001999-contrib:dead/enhance-2, r=pnkfelix
* 2724aeaaeb Rollup merge of #126618 - mu001999-contrib:dead/enhance, r=pnkfelix
* 977c5fd419 Rollup merge of #126315 - mu001999-contrib:fix/126289, r=petrochenkov
* 13314df21b Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix
There is an additional change stacked on top, which suppresses false-negatives that were masked by this work. I believe the functions that are touched in that code are legitimately unused functions and the types are not reachable since this `AnonPipe` type is not publically reachable -- please correct me if I'm wrong cc `@NobodyXu` who added these in ##127153.
Some of these reverts (#126315 and #126618) are only included because it makes the revert apply cleanly, and I think these changes were only done to fix follow-ups from the other PRs?
I apologize for the size of the PR and the churn that it has on the codebase (and for reverting `@mu001999's` work here), but I'm putting this PR up because I am concerned that we're making ad-hoc changes to fix bugs that are fallout of these PRs, and I'd like to see these changes reimplemented in a way that's more separable from the existing dead code pass. I am happy to review any code to reapply these changes in a more separable way.
cc `@mu001999`
r? `@pnkfelix`
Fixes#128272Fixes#126169
nested aux-build in tests/rustdoc/ tests
* Fixes bug that prevented using nested aux-build in `tests/rustdoc/` tests. Before, `fn document` and the auxiliary builder disagreed about where to find the nested aux-build source file (`auxiliary/auxiliary/aux.rs` vs `auxiliary/aux.rs`), preventing them from building. Picked the latter in line with other builders in compiletest.
* Adds `//@ doc-flags` header, which forwards flags to rustdoc and not rustc.
* Adds `//@ unique-doc-out-dir` header, which sets the --out-dir for the rustdoc invocation to a unique directory: `<root out dir>/docs/<test name>/doc`
* Changes working directory of the rustdoc invocation to the root out directory (common among all aux-builds). Prior art: exec_compiled_test in runtest.rs
* Adds tests that use nested aux builds and new headers
These changes provide useful capabilities for writing rustdoc tests on their own. They are also needed to test the implementation for the [mergable-rustdoc-cross-crate-info](https://github.com/rust-lang/rfcs/pull/3662) RFC.
try-job: x86_64-msvc
Migrate `cross-lang-lto-clang` and `cross-lang-lto-pgo-smoketest` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This has the same problem outlined by #126180, where the tests do not actually run as no test-running CI enviroment has `RUSTBUILD_FORCE_CLANG_BASED_TESTS` set.
However, I still find it interesting to turn the Makefiles into the rmake format until the Clang issue is fixed.
This should technically be tested on MSVC... if MSVC actually ran Clang tests.
try-job: x86_64-gnu-debug
Migrate `link-cfg` and `rustdoc-default-output` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
try-job: i686-msvc
the bug was caused by two factors:
1. only checking the RUST_TARGET_PATH form, not the full filepath form
2. indirectly trying to use the Debug presentation to get the file path
Migrate `cross-lang-lto` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
try-job: x86_64-msvc
try-job: i686-mingw
try-job: x86_64-mingw
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
Rollup of 6 pull requests
Successful merges:
- #126818 (Better handle suggestions for the already present code and fix some suggestions)
- #128436 (Update sysinfo version to 0.31.2)
- #128453 (raw_eq: using it on bytes with provenance is not UB (outside const-eval))
- #128491 ([`macro_metavar_expr_concat`] Dogfooding)
- #128494 (MIR required_consts, mentioned_items: ensure we do not forget to fill these lists)
- #128521 (rustdoc: Remove dead opaque_tys rendering logic)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Remove dead opaque_tys rendering logic
#127276 removed OpaqueTy from clean, and the code populating AllTypes::opaque_tys, but not this field itself.
raw_eq: using it on bytes with provenance is not UB (outside const-eval)
The current behavior of raw_eq violates provenance monotonicity. See https://github.com/rust-lang/rust/pull/124921 for an explanation of provenance monotonicity. It is violated in raw_eq because comparing bytes without provenance is well-defined, but adding provenance makes the operation UB.
So remove the no-provenance requirement from raw_eq. However, the requirement stays in-place for compile-time invocations of raw_eq, that indeed cannot deal with provenance.
Cc `@rust-lang/opsem`
Update sysinfo version to 0.31.2
I needed to update `memchr` version (which was pinned in 36a16798f7). So let's see if it triggers the linker issue.
try-job: x86_64-mingw
Better handle suggestions for the already present code and fix some suggestions
When a suggestion part is for code that is already present, skip it. If all the suggestion parts for a suggestion are for code that is already there, do not emit the suggestion.
Fix two suggestions that treat `span_suggestion` as if it were `span_help`.
When a suggestion part is for already present code, do not highlight it. If after that there are no highlights left, do not show the suggestion at all.
Fix clippy lint suggestion incorrectly treated as `span_help`.
interpret: on a signed deref check, mention the right pointer in the error
When a negative offset (like `ptr.offset(-10)`) goes out-of-bounds, we currently show an error saying that we expect the *resulting* pointer to be inbounds for 10 bytes. That's confusing, so this PR makes it so that instead we say that we expect the *original* pointer `ptr` to have 10 bytes *to the left*.
I also realized I can simplify the pointer arithmetic logic and handling of "staying inbounds of a target `usize`" quite a bit; the second commit does that.
Add target page for riscv64gc-unknown-linux-gnu
I was reading https://github.com/rust-lang/rust/issues/113739 and realized I knew most of the information necessary to create the `riscv64gc-unknown-linux-gnu` target page.
improve bootstrap to allow selecting llvm tools individually
Everything works as before, + now bootstrap allows for individually selecting LLVM tools (e.g., `x dist opt llvm-dis`) to include in the dist artifact.
Migrate `symbol-visibility` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Pretty scary!
- The expected number of symbols on each check has been changed slightly to reflect the differences between `llvm_readobj` and `nm`, as I think the former will print hidden symbols once and visible symbols twice, while the latter will only print visible symbols.
- The original test ran the same exact checks on `cdylib` twice, for seemingly no reason. I have removed it.
- This may be possible to optimize some more? `llvm_readobj` could get called only once for each library type, and the regex could avoid being created repeatedly. I am not sure if these kinds of considerations are important for a `run-make` test.
Demands a Windows try-job.
try-job: x86_64-mingw
Add myself as VxWorks target maintainer for reference
Hi, would be working on VxWorks regularly, thus adding myself as a target maintainer.
r? ```@workingjubilee```
Rollup of 9 pull requests
Successful merges:
- #126454 (bump-stage0: use IndexMap for determinism)
- #127681 (derive(SmartPointer): rewrite bounds in where and generic bounds)
- #127830 (When an archive fails to build, print the path)
- #128151 (Structured suggestion for `extern crate foo` when `foo` isn't resolved in import)
- #128387 (More detailed note to deprecate ONCE_INIT)
- #128388 (Match LLVM ABI in `extern "C"` functions for `f128` on Windows)
- #128402 (Attribute checking simplifications)
- #128412 (Remove `crate_level_only` from `ELIDED_LIFETIMES_IN_PATHS`)
- #128430 (Use a separate pattern type for `rustc_pattern_analysis` diagnostics )
r? `@ghost`
`@rustbot` modify labels: rollup
