Moves the sanitizer ui tests to the sanitizer directory and removes the
sanitizer prefix from tests file names similarly to how the sanitizer
codegen tests are organized.
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
Fix typo in `rustc_passes/messages.ftl`
Line 190 contains unpaired parentheses:
```
passes_doc_cfg_hide_takes_list =
`#[doc(cfg_hide(...)]` takes a list of attributes
```
The `#[doc(cfg_hide(...)]` contains unpaired parentheses. This PR changes it to `#[doc(cfg_hide(...))]`, which made the parentheses paired.
Implement unwind safety for Condvar on all platforms
Closes#118009
This commit adds unwind safety consistency to Condvar. Previously, only select platforms implemented unwind safety through auto traits. Known by this committer: On Linux, `Condvar` implemented `UnwindSafe` but on Mac and Windows, it did not. This change changes the implementation from auto to explicit.
In #118009, it was suggested that the platform differences were a bug and that a simple PR could address this. In trying to determine the best information to put in the `#[stable]` attribute, it [was suggested](https://github.com/rust-lang/rust/issues/121690#issuecomment-1968298470) I copy the stability information from the previous unwind safety implementations.
Restore the standard library review rotation to its former glory
This adds 7 reviewers to the standard library review rotation, bringing the total back up to 10 people. Specifically:
* On the main rotation: ``@cuviper`` ``@Mark-Simulacrum`` ``@m-ou-se`` ``@Amanieu`` ``@Nilstrieb`` ``@workingjubilee`` ``@joboet`` ``@jhpratt``
* For `core` only: ``@scottmcm``
* For `std` only: ``@ChrisDenton``
For everyone pinged here, please confirm that you are happy to be added to the review rotation.
Deeply normalize obligations in `refining_impl_trait`
We somewhat awkwardly use semantic comparison when checking the `refining_impl_trait` lint. This relies on us being able to normalize bounds eagerly to avoid cases where an unnormalized alias is not considered equal to a normalized alias. Since `normalize` in the new solver is a noop, let's use `deeply_normalize` instead.
r? lcnr
cc ``@tmandry,`` this should fix your bug lol
Have `String` use `SliceIndex` impls from `str`
This PR simplifies the implementation of `Index` and `IndexMut` on `String`, and in the process enables indexing `String` by any user types that implement `SliceIndex<str>`.
Similar to #47832
r? libs
Not sure if this warrants a crater run.
Increase visibility of `join_path` and `split_paths`
Add some crosslinking among `std::env` pages to make it easier to discover `join_paths` and `split_paths`. Also add aliases to help anyone searching for `PATH`.
And likewise with `ColorConfig::suggests_using_colors`. They both have a
single call site. And note that `BufWriter::supports_color()` always
returns false, which enables a small bit of constant folding along the
way.