Remove mono item collection strategy override from -Zprint-mono-items
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.
Update miniz_oxide dependency of coverage_dump
This was the final subproject that depended on ```miniz_oxide``` 0.7.x after the rest were when updating the ```backtrace-rs``` dependency in in #140705. Older versions of ```miniz_oxide``` got hit by a [serious](https://github.com/rust-lang/rust/issues/132636) performance regression in rust 1.82 (which has been worked around in more recent versions of the library) so should really be avoided if possible (granted it only affects compression so not sure if it had much impact in practice here, though there have also been some other performance improvements since .)
This also means no longer having to build two versions of miniz_oxide as everything can now use the same version, and no longer needing to build both ```adler``` and ```adler2```
Async drop fix for async_drop_in_place<T> layout for unspecified T
Fix for https://github.com/rust-lang/rust/issues/140423.
Layout of `async_drop_in_place<T>::{closure}` is calculated for unspecified T from dataflow_const_prop `try_make_constant`.
`@oli-obk,` do you think, it may be a better solution to add check like `if !args[0].is_fully_specialized() { return None; }` in `fn async_drop_coroutine_layout`?
And could you, pls, recommend, how to implement `is_fully_specialized()` in a most simple way?
Partially stabilize LoongArch target features
Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.
Specifically, this PR stabilizes the following target features:
* f
* d
* frecipe
* lasx
* lbt
* lsx
* lvz
Docs PR: https://github.com/rust-lang/reference/pull/1707
r? `@Amanieu`
Rollup of 7 pull requests
Successful merges:
- #140792 (Use intrinsics for `{f16,f32,f64,f128}::{minimum,maximum}` operations)
- #140795 (Prefer to suggest stable candidates rather than unstable ones)
- #140865 (Make t letter looks like lowercase rather than uppercase)
- #140878 (Two expand-related cleanups)
- #140882 (Split duration_constructors to get non-controversial constructors out)
- #140886 (Update deps of bootstrap for Cygwin)
- #140903 (test intrinsic fallback bodies with Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
test intrinsic fallback bodies with Miri
`@Urgau` noted in https://github.com/rust-lang/rust/pull/140792 that fallback bodies our backends don't use are untested... which is correct, and it is a problem. So this adds a testing-only flag to Miri to force the use of fallback bodies, and adds a run of the Miri test suite with that flag to CI. This should not take much more than a minute so I hope it's fine? Let's see how long it actually takes.
While at it, I made that test run also enable MIR optimizations. Miri's CI has a run with that, and it has caught mir-opt bugs in the past -- this way we'd see the CI failure earlier.
r? `@scottmcm`
Update deps of bootstrap for Cygwin
This PR just runs
```
cargo update fd-lock xattr libc errno
```
It reduces dependency on `rustix 0.38.40` and updates `libc` & `errno`. Now it compiles successfully on Cygwin:)
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
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.
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.
rust-analyzer doesn't construct `DerefPattern(_)` constructors, so these
shouldn't crash. It looks like this is how slice patterns are
implemented too.
Stabilize proc_macro::Span::{file, local_file}.
Stabilizes this part of https://github.com/rust-lang/rust/issues/54725:
```rust
impl Span {
pub fn file(&self) -> String; // Mapped/artificial file name, for display purposes.
pub fn local_file(&self) -> Option<PathBuf>; // Real file name as it exists on the local file system.
}
```
See also the naming discussion in https://github.com/rust-lang/rust/issues/139903
Be a bit more relaxed about not yet constrained infer vars in closure upvar analysis
See the writeup in `tests/ui/closures/opaque-upvar.rs`.
TL;DR is that this has to do with the fact that the recursive revealing uses, which have not yet been constrained from the defining use by the time that closure upvar inference is performed, remain as infer vars during upvar analysis. We don't really care, though, since anywhere we structurally match on a type in upvar analysis, we already call `structurally_resolve_type` right before `.kind()`, which would emit a true ambiguity error.
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/197
r? lcnr
