Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes#138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
Rollup of 8 pull requests
Successful merges:
- #140095 (Eliminate `word_and_empty` methods.)
- #140341 (Clarify black_box warning a bit)
- #140684 (Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided)
- #140707 (Structurally normalize in range pattern checking in HIR typeck)
- #140716 (Improve `-Zremap-path-scope` tests with dependency)
- #140800 (Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux)
- #140802 (Add release notes for 1.87.0)
- #140811 (Enable triagebot note functionality for rust-lang/rust)
r? `@ghost`
`@rustbot` modify labels: rollup
Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided
Since #136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given:
```rust
trait Trait {
type Assoc where Self: Sized;
}
```
After #136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing.
After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list.
This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before #136458.
We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in #136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future.
Fixes#140645
r? lcnr
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
make it possible to run in-tree rustfmt with `x run rustfmt`
Currently, there is no way to run in-tree `rustfmt` using `x fmt` or `x test tidy` commands. This PR implements `rustfmt` on `x run`, which allows bootstrap to run the in-tree `rustfmt`.
Fixes#140723
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
add armv5te-unknown-linux-gnueabi target maintainer
My employer is interested in having this target maintained and we already have some tests in our CI running for it.
armv5te-unknown-linux-gnueabi can be ticket off in #113739.
Fix regression from #140393 for espidf / horizon / nuttx / vita
#140393 introduced changes to the layout of the `std::sys::process` code.
As a result, the Tier 3 ESP-IDF (and I suspect Horizon, Nuttx and Vita targets as well) no longer build.
A `pub use unsupported::output` is all that was missing - for the above OSes specifically. This explicit `pub use` is now necessary, because #140393 moved the `output` function to module-level, where it was previously part of `Command` and was thus re-exported automatically, as part of the `imp::Command` re-export further down the file containing the one-liner fix.
Note that - with the change introduced by #140393 - we **can't** anymore just do an unconditional `pub use imp::output` as this function simply does not exist anymore anywhere else but in the `unsupported` module.
r? `@joboet`
[rustdoc] Ensure that temporary doctest folder is correctly removed even if doctests failed
Fixes#139899.
The bug was due to the fact that if any doctest fails for any reason, we call `exit` (or it's called inside `libtest` if not edition 2024), meaning that `TempDir`'s destructor isn't called, and therefore the temporary folder isn't cleaned up.
Took me a while to figure out how to reproduce but finally I was able to reproduce the bug with:
`````rust
#![doc(test(attr(deny(warnings))))]
//! ```
//! let a = 12;
//! ```
`````
And then I ensured that panicking doctests were cleaned up as well:
`````rust
//! ```
//! panic!();
//! ```
`````
And finally I checked if it was fixed for merged doctests too (`--edition 2024`).
To make this work, I needed to add a new public function in `libtest` too which would call a function once all tests have been run.
So only issue is: I have absolutely no idea how we can add a regression test for this fix. If anyone has an idea...
r? `@notriddle`
Don't crash on error codes passed to `--explain` which exceed our internal limit of 9999
removed panic in case where we do `--explain > 9999` and added check for it
now error looks like this instead of ICE
```
$ rustc.exe --explain E10000
error: E10000 is not a valid error code
```
fixes#140647
r? `@fmease`
Parser: Recover error from named params while parse_path
Fixes#140169
I added test to the first commit and the second added the code and changes to test.
r? `@petrochenkov`
Separate dataflow analysis and results
`Analysis` gets put into `Results` with `EntryStates`, by `iterate_to_fixpoint`. This has two problems:
- `Results` is passed various places where only `Analysis` is needed.
- `EntryStates` is passed around mutably everywhere even though it is immutable.
This commit mostly separates `Analysis` from `Results` and fixes these two problems.
r? `@davidtwco`
Use thread local dep graph encoding
This adds thread local encoding of dep graph nodes. Each thread has a `MemEncoder` that gets flushed to the global `FileEncoder` when it exceeds 64 kB. Each thread also has a local cache of dep indices. This means there can now be empty gaps in `SerializedDepGraph`.
Indices are marked green and also allocated by the new atomic operation `DepNodeColorMap::try_mark_green` as the encoder lock is removed.
Tshepang Mbambo
bors
Stan Manilov
Tomasz Miąsko
Matthias Krüger
Jakub Beránek
Boxy
The rustc-dev-guide Cronjob Bot
Guillaume Gomez