Do not deny warnings in "fast" try builds
When we do the classic ``@bors` try` build without specifying `try-job` in the PR description, we want to get a compiler toolchain for perf./crater/local experimentation as fast as possible. We don't run any tests in that case, so it seems reasonable to also ignore warnings.
Fixes: https://github.com/rust-lang/rust/issues/140753
r? `@jieyouxu`
try-job: dist-x86_64-linux
[win][arm64] Disable various DebugInfo tests that don't work on Arm64 Windows
While trying to get the aarch64-msvc build working correctly (#140136), various DebugInfo related tests were failing.
I've added comments to each test to indicate why it is disabled and linked to appropriate bugs.
* `tests/debuginfo/step-into-match.rs`: Stepping at the end of a function on goes to the callsite, not the instruction after it.
* `tests/debuginfo/type-names.rs`: Arm64 Windows cdb doesn't support JavaScript extensions. Followed up with the Microsoft Debugger Tools team to fix this.
* `tests/ui/runtime/backtrace-debuginfo.rs`: Backtraces are truncated due to #140489
Only prefer param-env candidates if they remain non-global after norm
Introduce `CandidateSource::GlobalParamEnv`, and dynamically compute the `CandidateSource` based on whether the predicate contains params *post-normalization*.
This code needs some cleanup and documentation. I'm just putting this up for review.
cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/179
r? lcnr
allow deref patterns to participate in exhaustiveness analysis
Per [this proposal](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Exhaustiveness), this PR allows deref patterns to participate in exhaustiveness analysis. Currently all deref patterns enforce `DerefPure` bounds on their scrutinees, so this assumes all patterns it's analyzing are well-behaved. This also doesn't support [mixed exhaustiveness](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Mixed-exhaustiveness), and instead emits an error if deref patterns are used together with normal constructors. I think mixed exhaustiveness would be nice to have (especially if we eventually want to support arbitrary `Deref` impls[^1]), but it'd require more work to get reasonable diagnostics[^2].
Tracking issue for deref patterns: #87121
r? `@Nadrieril`
[^1]: Regardless of whether we support limited exhaustiveness checking for untrusted `Deref` or always require other arms to be exhaustive, I think it'd be useful to allow mixed matching for user-defined smart pointers. And it'd be strange if it worked there but not for `Cow`.
[^2]: I think listing out witnesses of non-exhaustiveness can be confusing when they're not necessarily disjoint, and when you only need to cover some of them, so we'd probably want special formatting and/or explanatory subdiagnostics. And if it's implemented similarly to unions, we'd probably also want some way of merging witnesses; the way witnesses for unions can appear duplicated is pretty unfortunate. I'm not sure yet how the diagnostics should look, especially for deeply nested patterns.
run-make-support: set rustc dylib path for cargo wrapper
Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to execute correctly when rustc is built without rpath. In these setups, runtime loading of rustc’s shared libraries fails unless the appropriate dynamic library path is set manually.
This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(), aligning its behavior with the existing rustc() wrapper: f76c7367c6/src/tools/run-make-support/src/external_deps/rustc.rs (L39-L43)
This ensures that Cargo invocations during tests inherit the necessary dylib paths, avoiding errors related to missing shared libraries in rpath-less builds.
Fixes part of #140738
Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to
execute correctly when rustc is built without rpath. In these setups, runtime
loading of rustc’s shared libraries fails unless the appropriate dynamic library
path is set manually.
This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(),
aligning its behavior with the existing rustc() wrapper:
f76c7367c6/src/tools/run-make-support/src/external_deps/rustc.rs (L39)
This ensures that Cargo invocations during tests inherit the necessary dylib
paths, avoiding errors related to missing shared libraries in rpath-less builds.
Fixes part of #140738
rust-analyzer doesn't construct `DerefPattern(_)` constructors, so these
shouldn't crash. It looks like this is how slice patterns are
implemented too.
coverage-dump: Resolve global file IDs to filenames
The coverage-dump tool, used by coverage tests, currently includes “global file ID” numbers in its dump output.
This PR adds support for parsing coverage filename information from LLVM assembly `.ll` files, and resolving those file IDs to the corresponding filename, for inclusion in dump output.
This makes dump output more informative, especially for test cases involving multiple files, and will be important for testing expansion region support in the future.
---
The bootstrap changes don't necessarily have to land at the same time (e.g. they could be deferred to after the stage0 redesign if requested), but I would prefer to land them now if possible.
compiletest: Do not require annotations on empty labels and suggestions
Unlike other empty diagnostics, empty labels (only underlining spans) and empty suggestions (suggestions to remove something) are quite usual and do not require any special attention and annotations.
This effectively reverts a part of https://github.com/rust-lang/rust/pull/139485.
r? `@jieyouxu`
