Matthias Krüger [Thu, 29 Dec 2022 17:24:29 +0000 (18:24 +0100)]
Rollup merge of #104531 - ohno418:recover-fn-traits-with-lifetime-params, r=estebank
Provide a better error and a suggestion for `Fn` traits with lifetime params
Given `Fn`-family traits with lifetime params in trait bounds like `fn f(_: impl Fn<'a>(&'a str) -> bool)`, we currently produce many unhelpful errors.
This PR allows these situations to suggest simply using Higher-Rank Trait Bounds like `for<'a> Fn(&'a str) -> bool`.
bors [Thu, 29 Dec 2022 11:20:50 +0000 (11:20 +0000)]
Auto merge of #106195 - Nilstrieb:no-more-being-clueless-whether-it-really-is-a-literal, r=compiler-errors
Improve heuristics whether `format_args` string is a source literal
Previously, it only checked whether there was _a_ literal at the span of the first argument, not whether the literal actually matched up. This caused issues when a proc macro was generating a different literal with the same span.
This requires an annoying special case for literals ending in `\n` because otherwise `println` wouldn't give detailed diagnostics anymore which would be bad.
bors [Thu, 29 Dec 2022 04:22:25 +0000 (04:22 +0000)]
Auto merge of #105590 - solid-rs:patch/kmc-solid/thread-lifecycle-ordering, r=m-ou-se
kmc-solid: Fix memory ordering in thread operations
Fixes two memory ordering issues in the thread state machine (`ThreadInner::lifecycle`) of the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.
1. When detaching a thread that is still running (i.e., the owner updates `lifecycle` first, and the child updates it next), the first update did not synchronize-with the second update, resulting in a data race between the first update and the deallocation of `ThreadInner` by the child thread.
2. When joining on a thread, the joiner has to pass its own task ID to the joinee in order to be woken up later, but in doing so, it did not synchronize-with the read operation, creating possible sequences of execution where the joinee wakes up an incorrect or non-existent task.
Both issue are theoretical and most likely have never manifested in practice because of the stronger guarantees provided by the Arm memory model (particularly due to its barrier-based definition). Compiler optimizations could have subverted this, but the inspection of compiled code did not reveal such optimizations taking place.
bors [Thu, 29 Dec 2022 01:24:26 +0000 (01:24 +0000)]
Auto merge of #105741 - pietroalbini:pa-1.68-nightly, r=Mark-Simulacrum
Bump master bootstrap compiler
This PR bumps the bootstrap compiler to the beta created earlier this week, cherry-picks the stabilization version number updates, and updates the `cfg(bootstrap)`s.
bors [Wed, 28 Dec 2022 22:15:27 +0000 (22:15 +0000)]
Auto merge of #106228 - matthiaskrgr:rollup-jsznhww, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #104402 (Move `ReentrantMutex` to `std::sync`)
- #104493 (available_parallelism: Gracefully handle zero value cfs_period_us)
- #105359 (Make sentinel value configurable in `library/std/src/sys_common/thread_local_key.rs`)
- #105497 (Clarify `catch_unwind` docs about panic hooks)
- #105570 (Properly calculate best failure in macro matching)
- #105702 (Format only modified files)
- #105998 (adjust message on non-unwinding panic)
- #106161 (Iterator::find: link to Iterator::position in docs for discoverability)
Matthias Krüger [Wed, 28 Dec 2022 21:22:21 +0000 (22:22 +0100)]
Rollup merge of #105998 - RalfJung:no-unwind-panic-msg, r=thomcc
adjust message on non-unwinding panic
"thread panicked while panicking" is just plain wrong in case this is a non-unwinding panic, such as
- a panic out of a `nounwind` function
- the sanity checks we have in `mem::uninitialized` and `mem::zeroed`
- the optional debug assertion in various unsafe std library functions
Matthias Krüger [Wed, 28 Dec 2022 21:22:19 +0000 (22:22 +0100)]
Rollup merge of #105570 - Nilstrieb:actual-best-failure, r=compiler-errors
Properly calculate best failure in macro matching
Previously, we used spans. This was not good. Sometimes, the span of the token that failed to match may come from a position later in the file which has been transcribed into a token stream way earlier in the file. If precisely this token fails to match, we think that it was the best match because its span is so high, even though other arms might have gotten further in the token stream.
We now try to properly use the location in the token stream.
This needs a little cleanup as the `best_failure` field is getting out of hand but it should be mostly good to go. I hope I didn't violate too many abstraction boundaries..
Matthias Krüger [Wed, 28 Dec 2022 21:22:18 +0000 (22:22 +0100)]
Rollup merge of #105359 - flba-eb:thread_local_key_sentinel_value, r=m-ou-se
Make sentinel value configurable in `library/std/src/sys_common/thread_local_key.rs`
This is an excerpt of a changeset for the QNX/Neutrino OS. To make the patch for QNX smaller and easier to review, I've extracted this change (which is OS independent). I would be surprised if no other OS is also affected.
All this patch does is to define a `const` for a sentinel value instead of using it directly at several places.
There are OSs that always return the lowest free value. The algorithm in `lazy_init` always avoids keys with the sentinel value.
In affected OSs, this means that each call to `lazy_init` will always request two keys from the OS and returns/frees the first one (with sentinel value) immediately afterwards.
By making the sentinel value configurable, affected OSs can use a different value than zero to prevent this performance issue.
On QNX/Neutrino, it is planned to use a different sentinel value:
```rust
// Define a sentinel value that is unlikely to be returned
// as a TLS key (but it may be returned).
#[cfg(not(target_os = "nto"))]
const KEY_SENTVAL: usize = 0;
// On QNX/Neutrino, 0 is always returned when currently not in use.
// Using 0 would mean to always create two keys and remote the first
// one (with value of 0) immediately afterwards.
#[cfg(target_os = "nto")]
const KEY_SENTVAL: usize = libc::PTHREAD_KEYS_MAX + 1;
```
It seems like no other OS defines `PTHREAD_KEYS_MAX` in Rusts libc, but `limits.h` on unix systems does.
Matthias Krüger [Wed, 28 Dec 2022 21:22:18 +0000 (22:22 +0100)]
Rollup merge of #104493 - adamncasey:cgroupzeroperiod, r=m-ou-se
available_parallelism: Gracefully handle zero value cfs_period_us
There seem to be some scenarios where the cgroup cpu quota field `cpu.cfs_period_us` can contain `0`. This field is used to determine the "amount" of parallelism suggested by the function `std::thread::available_parallelism`
A zero value of this field cause a panic when `available_parallelism()` is invoked. This issue was detected by the call from binaries built by `cargo test`. I really don't feel like `0` is a good value for `cpu.cfs_period_us`, but I also don't think applications should panic if this value is seen.
This panic started happening with rust 1.64.0.
This case is gracefully handled by other projects which read this information: [num_cpus](https://github.com/seanmonstar/num_cpus/blob/e437b9d9083d717692e35d917de8674a7987dd06/src/linux.rs#L207-L210), [ninja](https://github.com/ninja-build/ninja/pull/2174/files), [dotnet](https://github.com/dotnet/runtime/blob/c4341d45acca3ea662cd8d71e7d71094450dd045/src/coreclr/pal/src/misc/cgroup.cpp#L481-L483)
Before this change, running `cargo test` in environments configured as described above would trigger this panic:
```
$ RUST_BACKTRACE=1 cargo test
Finished test [unoptimized + debuginfo] target(s) in 3.55s
Running unittests src/main.rs (target/debug/deps/x-9a42e145aca2934d)
thread 'main' panicked at 'attempt to divide by zero', library/std/src/sys/unix/thread.rs:546:70
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::panicking::panic
3: std::sys::unix::thread::cgroups::quota
4: std::sys::unix::thread::available_parallelism
5: std::thread::available_parallelism
6: test::helpers::concurrency::get_concurrency
7: test::console::run_tests_console
8: test::test_main
9: test::test_main_static
10: x::main
at ./src/main.rs:1:1
11: core::ops::function::FnOnce::call_once
at /tmp/rust-1.64-1.64.0-1/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: test failed, to rerun pass '--bin x'
```
I've tested this change in an environment which has the bad (questionable?) setup and rebuilding the test executable against a fixed std library fixes the panic.
Nilstrieb [Tue, 27 Dec 2022 21:15:25 +0000 (22:15 +0100)]
Improve heuristics whether `format_args` string is a source literal
Previously, it only checked whether there was _a_ literal at the span of
the first argument, not whether the literal actually matched up. This
caused issues when a proc macro was generating a different literal with
the same span.
This requires an annoying special case for literals ending in `\n`
because otherwise `println` wouldn't give detailed diagnostics anymore
which would be bad.
bors [Wed, 28 Dec 2022 13:07:30 +0000 (13:07 +0000)]
Auto merge of #106129 - compiler-errors:compare_method-tweaks, r=BoxyUwU
Some `compare_method` tweaks
1. Make some of the comparison functions' names more regular
2. Reduce pub scope of some of the things in `compare_method`
~3. Remove some unnecessary opaque type handling code -- `InferCtxt` already is in a mode that doesn't define opaque types~
* moved to a different PR
4. Bubble up `ErrorGuaranteed` for region constraint errors in `compare_method` - Improves a redundant error message in one unit test.
5. Move the `compare_method` module to have a more general name, since it's more like `compare_impl_item` :)
6. Rename `collect_trait_impl_trait_tys`
fee1-dead [Wed, 28 Dec 2022 07:51:43 +0000 (15:51 +0800)]
Rollup merge of #106205 - compiler-errors:oopsy, r=fee1-dead
Remove some totally duplicated files in `rustc_infer`
I have no idea why or how I duplicated these files from `compiler/rustc_infer/src/infer/error_reporting/note.rs`, but I did by accident, and nothing caught it :facepalm:
```
error[E0308]: `match` arms have incompatible types
--> f53.rs:2:52
|
2 | let _ = match Some(42) { Some(x) => x, None => "" };
| -------------- - ^^ expected integer, found `&str`
| | |
| | this is found to be of type `{integer}`
| `match` arms have incompatible types
```
fee1-dead [Wed, 28 Dec 2022 07:51:40 +0000 (15:51 +0800)]
Rollup merge of #104708 - jonasspinner:fix-backoff-doc-to-match-implementation, r=compiler-errors
Fix backoff doc to match implementation
The commit 8dddb2294310ad3e8ce0b2af735a702ad72a9a99 in the crossbeam-channel PR (#93563) changed the backoff strategy to be quadratic instead of exponential. This updates the doc to prevent confusion.
```
error[E0308]: `match` arms have incompatible types
--> f53.rs:2:52
|
2 | let _ = match Some(42) { Some(x) => x, None => "" };
| -------------- - ^^ expected integer, found `&str`
| | |
| | this is found to be of type `{integer}`
| `match` arms have incompatible types
```
bors [Tue, 27 Dec 2022 20:54:06 +0000 (20:54 +0000)]
Auto merge of #106193 - compiler-errors:rollup-0l54wka, r=compiler-errors
Rollup of 9 pull requests
Successful merges:
- #103718 (More inference-friendly API for lazy)
- #105765 (Detect likely `.` -> `..` typo in method calls)
- #105852 (Suggest rewriting a malformed hex literal if we expect a float)
- #105965 (Provide local extern function arg names)
- #106064 (Partially fix `explicit_outlives_requirements` lint in macros)
- #106179 (Fix a formatting error in Iterator::for_each docs)
- #106181 (Fix doc comment parsing description in book)
- #106187 (Update the documentation of `Vec` to use `extend(array)` instead of `extend(array.iter().copied())`)
- #106189 (Fix UnsafeCell Documentation Spelling Error)
Michael Goulet [Tue, 27 Dec 2022 20:33:38 +0000 (12:33 -0800)]
Rollup merge of #106189 - alexhrao:master, r=Nilstrieb
Fix UnsafeCell Documentation Spelling Error
This fixes the spelling of "deallocated" (instead of the original "deallocted") In the `cell.rs` source file. Honestly probably not worth the time to evaluate, but since it doesn't involve any code change, I figure why not?
Michael Goulet [Tue, 27 Dec 2022 20:33:36 +0000 (12:33 -0800)]
Rollup merge of #106179 - RetroSeven:typo_fix, r=compiler-errors
Fix a formatting error in Iterator::for_each docs
There is a formatting error (extra space in an assignment) in the documentation of `core::iter::Iterator::for_each`, which I have fixed in this pull request.
Michael Goulet [Tue, 27 Dec 2022 20:33:33 +0000 (12:33 -0800)]
Rollup merge of #103718 - matklad:infer-lazy, r=dtolnay
More inference-friendly API for lazy
The signature for new was
```
fn new<F>(f: F) -> Lazy<T, F>
```
Notably, with `F` unconstrained, `T` can be literally anything, and just `let _ = Lazy::new(|| 92)` would not typecheck.
This historiacally was a necessity -- `new` is a `const` function, it couldn't have any bounds. Today though, we can move `new` under the `F: FnOnce() -> T` bound, which gives the compiler enough data to infer the type of T from closure.
bors [Tue, 27 Dec 2022 15:44:53 +0000 (15:44 +0000)]
Auto merge of #106183 - matthiaskrgr:rollup-ww6yzhi, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #105817 (Remove unreasonable help message for auto trait)
- #105994 (Add regression test for #99647)
- #106066 (Always suggest as `MachineApplicable` in `recover_intersection_pat`)
Matthias Krüger [Tue, 27 Dec 2022 15:37:48 +0000 (16:37 +0100)]
Rollup merge of #106066 - JohnTitor:rm-bindings-after-at-fixme, r=compiler-errors
Always suggest as `MachineApplicable` in `recover_intersection_pat`
This resolves one FIXME in `recover_intersection_pat` by always applying `MachineApplicable` when suggesting, as `bindings_after_at` is now stable.
This also separates a test to apply `// run-rustfix`.
bors [Tue, 27 Dec 2022 13:04:08 +0000 (13:04 +0000)]
Auto merge of #106168 - jyn514:clean-crates, r=Mark-Simulacrum
Allow cleaning individual crates
As a bonus, this stops special casing `clean` in `Builder`.
## Motivation
Cleaning artifacts isn't strictly necessary to get cargo to rebuild; `touch compiler/rustc_driver/src/lib.rs` (for example) will also work. There's two reasons I thought making this part of bootstrap proper was a better approach:
1. `touch` does not *remove* artifacts, it just causes a rebuild. This is unhelpful for when you want to measure how long the compiler itself takes to build (e.g. for https://github.com/rust-lang/rust/issues/65031).
2. It seems a little more discoverable; and I want to extend it in the future to things like `x clean --stage 1 rustc`, which makes it easier to work around https://github.com/rust-lang/rust/issues/76720 without having to completely wipe all the stage 0 artifacts, or having to be intimately familiar with which directories to remove.
bors [Tue, 27 Dec 2022 10:23:32 +0000 (10:23 +0000)]
Auto merge of #106177 - matthiaskrgr:rollup-oe7z8ix, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #105515 (Account for macros in const generics)
- #106146 (Readme: update section on how to run `x.py`)
- #106150 (Detect when method call on LHS might be shadowed)
- #106174 (Remove unused empty CSS rules in ayu theme)
close https://github.com/rust-lang/rust/issues/42200
Add env variables and cwd to the shell-like debug output.
Also use the alternate syntax to display a more verbose display, while not showing internal fields and hiding fields when they have their default value.
Matthias Krüger [Tue, 27 Dec 2022 07:57:46 +0000 (08:57 +0100)]
Rollup merge of #106146 - kadiwa4:readme-x-py, r=jyn514
Readme: update section on how to run `x.py`
`./x.py` currently looks for `python3` (not `python`) in the `PATH`. I updated that in the readme and also mentioned a convenient way to run `x.py` on Windows. The PowerShell script is actually quite inconvenient to use (and not really necessary on the `cmd.exe` prompt) so I left it out.
In addition I adapted `./x` in one of the CI scripts.