disable diagnostic deduplication
`@oli-obk` is there a better way to do this? Ideally we'd only set this when interpretation starts but the value in the compiler session seems to be immutable. I assume people will do `cargo check` before `cargo miri` so hopefully this won't lead to too much confusion.
Fixes https://github.com/rust-lang/miri/issues/3350
Fix .\miri fmt on Windows
This allows .\miri fmt to work on Windows. Closes#3317.
To reiterate, the problem with using `miri fmt` on Windows is that the CLI arguments to rustfmt are too long. Currently over 65,000 characters are used in the call to rustfmt, [which is incompatible with Windows](https://devblogs.microsoft.com/oldnewthing/20031210-00/?p=41553) as it is limited to (2^15 - 1) for all arguments plus all env vars.
Two things are done do get around this limit:
1. Call out to cargo-fmt for the crates that exist.
2. Batch rustfmt calls by length
Another alternative would be to just use rustfmt for everything and don't use cargo-fmt for the crates.
I don't know how much you guys may care about `miri fmt` time to run. I don't know the diff as it did not work before on my computer.
[I have another branch that solves this, but in a less permanent way](RossSmyth/miri/tree/windows-fmt). That was my initial attempt, and I learned that even with cargo-fmt and relative paths, the rustfmt call still has 27k characters. This is closer to the limit than I expected, so it would not be a permanent solution. So I went back to absolute paths & batching.
log when we change the active thread, and fix logging for concurrency
Also avoid relying on the incorrect scope exit logging produced by tracing (Cc https://github.com/rust-lang/miri/issues/2266)
print thread name in miri error backtraces; add option to track read/write accesses
This came up while debugging https://github.com/rust-lang/rust/issues/121626. It didn't end up being useful there but still seems like good tools to have around.
Emitter cleanups
Some cleanups I made when reading emitter code. In particular, `HumanEmitter` and `JsonEmitter` have gone from three constructors to one.
r? `@oli-obk`
Count stashed errors again
Stashed diagnostics are such a pain. Their "might be emitted, might not" semantics messes with lots of things.
#120828 and #121206 made some big changes to how they work, improving some things, but still leaving some problems, as seen by the issues caused by #121206. This PR aims to fix all of them by restricting them in a way that eliminates the "might be emitted, might not" semantics while still allowing 98% of their benefit. Details in the individual commit logs.
r? `@oli-obk`
Use volatile access instead of `#[used]` for `on_tls_callback`
The first commit adds a volatile load of `p_thread_callback` when registering a dtor so that the compiler knows if the callback is used or not. I don't believe the added volatile instruction is otherwise significant in the context. In my testing using the volatile load allowed the compiler to correctly reason about whether `on_tls_callback` is used or not, allowing it to be omitted entirely in some cases. Admittedly it usually is used due to `Thread` but that can be avoided (e.g. in DLLs or with custom entry points that avoid the offending APIs). Ideally this would be something the compiler could help a bit more with so we didn't have to use tricks like `#[used]` or volatile. But alas.
I also used this as an opportunity to clean up the `unused` lints which I don't think serve a purpose any more.
The second commit removes the volatile load of `_tls_used` with `#cfg[target_thread_local]` because `#[thread_local]` already implies it. And if it ever didn't then `#[thread_local]` would be broken when there aren't any dtors.
Skip unnecessary comparison with half-open range patterns
This is the last remaining detail in the implementation of half-open range patterns. Until now, a half-open range pattern like `10..` was converted to `10..T::MAX` before lowering to MIR, which generated an extra pointless comparison. With this PR we don't generate it.
pattern_analysis: rework how we hide empty private fields
Consider this:
```rust
mod foo {
pub struct Bar {
pub a: bool,
b: !,
}
}
fn match_a_bar(bar: foo::Bar) -> bool {
match bar {
Bar { a, .. } => a,
}
}
```
Because the field `b` is private, matches outside the module are not allowed to observe the fact that `Bar` is empty. In particular `match bar {}` is valid within the module `foo` but an error outside (assuming `exhaustive_patterns`).
We currently handle this by hiding the field `b` when it's both private and empty. This means that the pattern `Bar { a, .. }` is lowered to `Bar(a, _)` if we're inside of `foo` and to `Bar(a)` outside. This involves a bit of a dance to keep field indices straight. But most importantly this makes pattern lowering depend on the module.
In this PR, I instead do nothing special when lowering. Only during analysis do we track whether a place must be skipped.
r? `@compiler-errors`
Improve renaming suggestion when item starts with underscore
Fixes https://github.com/rust-lang/rust/issues/121776.
It goes from:
```terminal
error[E0433]: failed to resolve: use of undeclared type `Foo`
--> src/foo.rs:6:13
|
6 | let _ = Foo::Bar;
| ^^^ use of undeclared type `Foo`
|
help: an enum with a similar name exists, consider changing it
|
1 | enum Foo {
| ~~~
```
to:
```terminal
error[E0433]: failed to resolve: use of undeclared type `Foo`
--> foo.rs:6:13
|
6 | let _ = Foo::Bar;
| ^^^ use of undeclared type `Foo`
|
help: an enum with a similar name exists, consider renaming `_Foo` into `Foo`
|
1 | enum Foo {
| ~~~
error: aborting due to 1 previous error
```
bootstrap/format: send larger batches to rustfmt
This helps on systems with low core counts. To benchmark this I made a lot of files be modified:
```
for FILE in $(find compiler/ -name "*.rs"); do echo "// end of the file" >>$FILE; done
```
Then I ran
```
hyperfine "./x.py fmt -j1" -w 1 -r 4
```
Before this patch:
```
Benchmark 1: ./x.py fmt -j1
Time (mean ± σ): 3.426 s ± 0.032 s [User: 4.681 s, System: 1.376 s]
Range (min … max): 3.389 s … 3.462 s 4 runs
```
With this patch:
```
Benchmark 1: ./x.py fmt -j1
Time (mean ± σ): 2.530 s ± 0.054 s [User: 4.042 s, System: 0.467 s]
Range (min … max): 2.452 s … 2.576 s 4 runs
```
add platform-specific function to get the error number for HermitOS
Extending `std` to get the last error number for HermitOS.
HermitOS is a tier 3 platform and this PR changes only files, wich are related to the tier 3 platform.
Fix `async Fn` confirmation for `FnDef`/`FnPtr`/`Closure` types
Fixes three issues:
1. The code in `extract_tupled_inputs_and_output_from_async_callable` was accidentally getting the *future* type and the *output* type (returned by the future) messed up for fnptr/fndef/closure types. :/
2. We have a (class of) bug(s) in the old solver where we don't really support higher ranked built-in `Future` goals for generators. This is not possible to hit on stable code, but [can be hit with `unboxed_closures`](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e935de7181e37e13515ad01720bcb899) (#121653).
* I'm opting not to fix that in this PR. Instead, I just instantiate placeholders when confirming `async Fn` goals.
4. Fixed a bug when generating `FnPtr` shims for `async Fn` trait goals.
r? oli-obk
