Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#155469 (Account for titlecase in casing lints)
- rust-lang/rust#155644 (delegation: support self ty propagation for functions in free to trait reuse)
- rust-lang/rust#154957 (Fix ICE when const closure appears inside a non-const trait method)
- rust-lang/rust#155442 (Change keyword order for `impl` restrictions)
- rust-lang/rust#155561 (Use singular wording for single _ placeholders in type suggestions)
- rust-lang/rust#155637 (Fix E0191 suggestion for empty dyn trait args)
- rust-lang/rust#155661 (Remove `AttributeLintKind` variants - part 6)
Change keyword order for `impl` restrictions
Based on rust-lang/rust#155222, this PR reorders keywords in trait definitions to group restrictions with visibility. It changes the order from `pub(...) const unsafe auto impl(...) trait Foo {...}` to `pub(...) impl(...) const unsafe auto trait Foo {...}`.
Tracking issue for restrictions: rust-lang/rust#105077
r? @Urgau
cc @jhpratt
Fix ICE when const closure appears inside a non-const trait method
Fixesrust-lang/rust#153891
`hir_body_const_context()` unconditionally delegated to the parent's const context for const closures, returning `None` when the parent had no const context. This caused `mir_const_qualif()` to hit a `span_bug!`, since `mir_promoted()` had already decided to call it based on the closure's own syntactic constness. Fall back to `ConstContext::ConstFn` when the parent's const context is `None`, so that the const closure body is still properly const-checked rather than triggering an ICE.
Examining [another attempt](https://github.com/rust-lang/rust/pull/153900/changes) at this issue (which has already been closed), I thought that its approach represents a workaround fix to avoid inconsistencies in the caller of `mir_promoted()`, whereas I think the correct behavior is for `hir_body_const_context()` itself to return the proper value.
delegation: support self ty propagation for functions in free to trait reuse
This PR adds support for self types specified in free to trait reuse. Up to this point we always generated `Self` despite the fact whether self type was specified or not. Now we use it in signature inheritance. Moreover we no more generate `Self` for static methods. Part of rust-lang/rust#118212.
```rust
trait Trait<T> {
fn foo<const B: bool>(&self) {}
fn bar() {}
}
impl<T> Trait<T> for usize {}
reuse <usize as Trait>::foo;
// Desugaring (no `Self` as usize is specified)
fn foo<T, const B: bool>(self: &usize) {
<usize as Trait::<T>>::foo::<B>(self)
}
reuse Trait::bar;
// Desugaring (no `Self` as static method)
fn bar<T>() {
Trait::<T>::bar(); //~ERROR: type annotations needed
}
```
r? @petrochenkov
Streamline `CrateMetadataRef` construction in `provide_one!`.
`cstore.get_crate_data()` creates a `CrateMetadataRef`, which is exactly what we need. The current code is very confused and does several unnecessary things: mapping the `FreezeReadGuard` and calling `CStore::from_tcx` a second time to construct a second `CrateMetadataRef`.
This is a small perf win.
r? @mu001999
rustc_llvm: update opt-level handling for LLVM 23
LLVM 23 removed Os and Oz optimization pipelines and the PR says to use O2 with optsize or minsize instead as appropriate.
See https://github.com/llvm/llvm-project/pull/191363 for more details.
Expand `Path::is_empty` docs
Give some reasons why you might want to check if a path is empty. The `Path::join` behaviour can be surprising if you're not aware it might happen.
Remove non-working code for "running" mir-opt tests
Tests in `tests/mir-opt` always use `--emit=mir`, so the compiler doesn't even produce an executable.
Attempting to "run" these tests (e.g. with `./x test mir-opt --pass=run`) therefore fails when the OS notices that a MIR text file is not executable.
---
The second commit performs some semi-related cleanup.
r? jieyouxu
Make `//@ skip-filecheck` a normal compiletest directive
The `skip-filecheck` directive is currently used by mir-opt tests, to suppress the default behaviour of running LLVM's `FileCheck` tool to check MIR output against FileCheck rules in the test file.
The `skip-filecheck` directive was not included in the big migration to `//@` directive syntax (https://github.com/rust-lang/rust/pull/121370), perhaps because it was parsed and processed in the *miropt-test-tools* helper crate, not in compiletest itself.
Recently I noticed that a small number of *codegen-llvm* tests were using the `//@ build-pass` directive, which has the non-obvious effect of skipping FileCheck in codegen tests. That's quite confusing, so I decided to have the mir-opt tests migrate over to a proper `//@ skip-filecheck` directive, which could then be used by codegen tests as well.
(I also added skip-filecheck support to assembly tests, which are very similar to codegen tests, though there are currently no assembly tests that actually use `//@ skip-filecheck`.)
---
Support for using `//@ build-pass` in codegen tests to skip FileCheck was introduced in https://github.com/rust-lang/rust/pull/113603. With hindsight, I think doing things that way was pretty clearly a mistake, and we'll be better off with `//@ skip-filecheck`.
r? jieyouxu
Improved assumptions relating to isqrt
Improved various assumptions relating to values yielded by `isqrt`.
Does not solve but does improve rust-lang/rust#132763.
Re-openeing of rust-lang/rust#154115
Added assumptions are:
* if `x` is nonzero then `x.isqrt()` is nonzero
* `x.isqrt() <= x`
* `x.isqrt() * x.isqrt() <= x`
rustc_thread_pool: Make `CoreLatch::set` use `SeqCst` instead of `AcqRel`
Every other modification of this variable uses `SeqCst`, which is justified in the sleep README. This particular choice of `AcqRel` was not discussed during its addition in rayon-rs/rayon#746, nor rayon-rs/rfcs#5, so I suspect was simply an oversight from earlier development. We probably do want this to participate in the same sequential consistency.
The only other ordering difference is `CoreLatch::probe`'s load with `Acquire`, which should be fine because this doesn't need consistency with the sleep counters.
See also rayon-rs/rayon#1297. As I commented there, I think in practice this would be quite rare to cause any problems, but it *could* be a source of non-deterministic bugs on targets with weak memory ordering.
Update to wasi-sdk-32 in CI/releases
Similar to prior updates such as rust-lang/rust#149037. This notably pulls in some bug fixes for wasi-libc around nonblocking I/O and networking.
Replace `ShardedHashMap` method `insert` with debug-checked `insert_unique`
Currently every use of `ShardedHashMap::insert` checks that it won't evict an old value due to unique key. I haven't found any issue related to that faulty condition, so I thought of replacing it with `ShardedHashMap::insert_unique` which doesn't check for this condition unless `debug_assertions` are enabled. This might improve the performance.
r? @petrochenkov
BinOpAssign always returns unit
I don't know why we treated assign ops as returning their binop type sometimes, but it's usually ignored later anyway and mostly affects infer vars.
Also updated a comment from 11 years ago when SIMD types apparently had builtin `==` logic.
Immediately feed visibility on DefId creation
This system was originally introduced in rust-lang/rust#121089
This PR was enabled by refactorings in rust-lang/rust#154945, because after that, the visibility feeding happens directly after the `DefId` creation, so we don't need to go through the intermediate hash table anymore
Should unblock rust-lang/rust#138995
Remove `nodes_in_current_session` field and related assertions
This removes the `nodes_in_current_session` field and related assertions. These are enabled if `-Z incremental-verify-ich` is passed or `debug_assertions` is on. Historically these have been useful to catch query keys with improper `HashStable` impls which lead to collisions.
We currently also check for duplicate nodes when loading the dep graph. This check is more complete as it covers the entire dep graph and is enabled by default. It doesn't provide a query key for a collision however. This check is also delayed to the next incremental session.
We also have the `verify_query_key_hashes` which is also enabled if `-Z incremental-verify-ich` is passed or `debug_assertions` is on. This checks for dep node conflicts in each query cache and provides 2 conflicting keys if present.
I think these remaining checks are sufficient and so we can remove `nodes_in_current_session`.
Document precision considerations of `Duration`-float methods
A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns),
so there's some inherent loss when converting to floating-point for
`mul_f64` and `div_f64`. We could go to greater lengths to compute these
with more accuracy, like rust-lang/rust#150933 or rust-lang/rust#154107,
but it's not clear that it's worth the effort. The least we can do is
document that some rounding is to be expected, which this commit does
with simple examples that only multiply or divide by `1.0`.
This also changes the `f32` methods to just forward to `f64`, so we keep
more of that duration precision, as the range is otherwise much more
limited there.
yukang