Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#148170 (split definition and use site hidden tys)
- rust-lang/rust#148194 (compiletest: Remove `cleanup_debug_info_options`)
- rust-lang/rust#148199 (compiletest: Don't modify `testpaths` when creating aux contexts)
- rust-lang/rust#148290 (Do not emit solver errors that contain error types)
- rust-lang/rust#148357 (temporary-lifetime-extension.rs test works in all editions)
- rust-lang/rust#148362 (docs: makes a note about possible building `rustc 1.91.0 + host tools` for win7)
- rust-lang/rust#148367 (Use --print host-tuple to get the host)
- rust-lang/rust#148374 (miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Use --print host-tuple to get the host
`--print host-tuple` has been available since 1.84 so there's no longer a need to parse the output of `-vV`. Especially since this script is shipped with the toolchain.
Do not emit solver errors that contain error types
any follow-up errors are going to either be duplicates or often disappear if the error itself is fixed.
in this PR it mostly silences dyn-compat errors as all the other errors are already deduplicated outside of the test suite. The dyn compat errors are independent errors and I think if the dyn compatiblity depended on an error type it would not actually show, so this is PR is actually silencing independent errors, too.
I am opening this PR because I am seeing lots of `{type error}: const Trait` errors when adding more const checking. So instead of targetting just those specific errors, I wanted to try out fully avoiding such errors near the trait solver.
cc ````@rust-lang/types```` for thoughts
compiletest: Don't modify `testpaths` when creating aux contexts
Modifying `TestCx::testpaths` makes it vastly harder to reason about how compiletest is using test paths, and can be avoided without much trouble by simply passing explicit source-file paths into a small number of auxiliary-aware methods.
---
This PR was originally based on a much larger change that split `TestPaths` into multiple structs and multiple `TestCx` fields (as seen in early revisions of https://github.com/rust-lang/rust/pull/148160), but after further cleanups it turned out that very few tweaks were actually needed to avoid changes to `testpaths`.
r? jieyouxu
compiletest: Remove `cleanup_debug_info_options`
This "cleanup" function is more than a decade old, and I can't find any evidence of modern-day bootstrap being able to pass any of these flags to `--host-rustcflags` or `--target-rustcflags`.
I thought about replacing the cleanup with an assertion, but I think it's better to delete it entirely for now, and re-add checks later if they're motivated by actual problems in practice.
In addition to deleting some old and confusing code, this also lets us remove three instances of duplicating `TestCx`, which is the biggest win.
r? jieyouxu
When a trait isn't implemented, but another similar impl is found, point at it
```
error[E0277]: the trait bound `u32: Trait` is not satisfied
--> $DIR/trait_objects_fail.rs:26:9
|
LL | foo(&10_u32);
| ^^^^^^^ the trait `Trait` is not implemented for `u32`
|
help: the trait `Trait<12>` is not implemented for `u32`
but trait `Trait<2>` is implemented for it
--> $DIR/trait_objects_fail.rs:7:1
|
LL | impl Trait<2> for u32 {}
| ^^^^^^^^^^^^^^^^^^^^^
= note: required for the cast from `&u32` to `&dyn Trait`
```
Pointing at the `impl` definition that *could* apply given a different self type is *particularly* useful when it has a blanket self type, as it might not be obvious and is not trivially greppable:
```
error[E0277]: the trait bound `RawImpl<_>: Raw<_>` is not satisfied
--> $DIR/issue-62742.rs:4:5
|
LL | WrongImpl::foo(0i32);
| ^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Raw<_>` is not implemented for `RawImpl<_>`
but trait `Raw<[_]>` is implemented for it
--> $DIR/issue-62742.rs:29:1
|
LL | impl<T> Raw<[T]> for RawImpl<T> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `SafeImpl`
--> $DIR/issue-62742.rs:33:35
|
LL | pub struct SafeImpl<T: ?Sized, A: Raw<T>>(PhantomData<(A, T)>);
| ^^^^^^ required by this bound in `SafeImpl`
```
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#135602 (Tweak output of missing lifetime on associated type)
- rust-lang/rust#139751 (Implement pin-project in pattern matching for `&pin mut|const T`)
- rust-lang/rust#142682 (Update bundled musl to 1.2.5)
- rust-lang/rust#148171 (Simplify code to generate line numbers in highlight)
- rust-lang/rust#148263 (Unpin `libc` and `rustix` in `compiler` and `rustbook`)
- rust-lang/rust#148301 ([rustdoc search] Include extern crates when filtering on `import`)
- rust-lang/rust#148330 (Don't require dlltool with the dummy backend on MinGW)
- rust-lang/rust#148338 (cleanup: upstream dropped amx-transpose functionality)
- rust-lang/rust#148340 (Clippy subtree update)
- rust-lang/rust#148343 (`nonpoison::Condvar` should take `MutexGuard` by reference)
r? `@ghost`
`@rustbot` modify labels: rollup
`nonpoison::Condvar` should take `MutexGuard` by reference
Feature: `#![feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
Specific comment: https://github.com/rust-lang/rust/issues/134645#issuecomment-3458525913
Changes the `nonpoison::Condvar` API to take `MutexGuard` by reference instead of ownership.
I'm actually not entirely sure why the current poison variant of `Condvar` takes by ownership, is it just legacy reasons?
Additionally, the `nonpoison_and_poison_unwrap_test` macro doesn't really make sense anymore now that the APIs are completely different, so this reverts that change from a few months ago.
r? ````@Amanieu````
cleanup: upstream dropped amx-transpose functionality
See also LLVM change 5322fb626820. Looks like this was just removed entirely.
It seems a little bad to just drop it, but I don't see an easy way to conditionalize
this and if it's really just Gone and we marked it as unstable (which it looks like
we did?) I guess we should just dump it.
````@rustbot```` label llvm-main
Don't require dlltool with the dummy backend on MinGW
The dummy backend should be able to cross-compile to any target without requiring any external tool or library other than the rust standard library.
For https://github.com/rust-lang/miri/pull/4648.
[rustdoc search] Include extern crates when filtering on `import`
As discussed https://github.com/rust-lang/rust/pull/147909, some filters should have been "grouped". This PR allows extern crates to match the `import` filter.
This PR also allowed me to uncover a bug for the URL generated for renamed extern crates. Opened rust-lang/rust#148300 for it.
r? `````@notriddle`````
Implement pin-project in pattern matching for `&pin mut|const T`
This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`.
~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~
CC ``````@traviscross``````
Tweak output of missing lifetime on associated type
Each commit can be reviewed independently. Address parts of #135589.
---
When an associated type is missing a lifetime, point at its enclosing `impl`, whether it has or doesn't have lifetimes defined. If it does have a lifetime, suggest using it.
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-1.rs:8:17
|
LL | impl<'a> IntoIterator for &S {
| ---- there is a named lifetime specified on the impl block you could use
...
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
help: consider using the lifetime from the impl block
|
LL | type Item = &'a T;
| ++
```
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17
|
LL | impl IntoIterator for &S {
| - you could add a lifetime on the impl block, if the trait or the self type can have one
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
```
---
On unconstrained lifetime on impl block, suggest using it if there's an implicit borrow in the self type
```
error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates
--> $DIR/missing-lifetime-in-assoc-type-1.rs:4:6
|
LL | impl<'a> IntoIterator for &S {
| ^^ unconstrained lifetime parameter
|
help: consider using the named lifetime here instead of an implict lifetime
|
LL | impl<'a> IntoIterator for &'a S {
| ++
```
---
Do not suggest introducing lifetime in impl assoc type
---
Previously we only showed the trait's assoc item if the trait was local, because we were looking for a small span only for the generics, which we don't have for foreign traits. We now use `def_span` for the item, so we at least provide some context, even if its span is too wide.
```
error[E0195]: lifetime parameters or bounds on type `IntoIter` do not match the trait declaration
--> tests/ui/lifetimes/missing-lifetime-in-assoc-type-4.rs:7:18
|
7 | type IntoIter<'a> = std::collections::btree_map::Values<'a, i32, T>;
| ^^^^ lifetimes do not match type in trait
|
::: /home/gh-estebank/rust/library/core/src/iter/traits/collect.rs:292:5
|
292 | type IntoIter: Iterator<Item = Self::Item>;
| ------------------------------------------ lifetimes in impl do not match this type in trait
```
Update cargo submodule
6 commits in 6c1b6100343691341b9e76c5acc594e78220f963..6368002885a04cbeae39a82cf5118f941559a40a
2025-10-28 16:27:52 +0000 to 2025-10-31 14:31:52 +0000
- feat(build-analysis): emit timing-info log (rust-lang/cargo#16179)
- Remove libc pin message (rust-lang/cargo#16182)
- feat(config-include): add optional field support (rust-lang/cargo#16180)
- feat(config-include): support inline and array of tables (rust-lang/cargo#16174)
- test(script): Update from rustc's test suite (rust-lang/cargo#16169)
- Fix links for options in man pages (rust-lang/cargo#16172)
r? ghost
```
error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates
--> $DIR/missing-lifetime-in-assoc-type-1.rs:4:6
|
LL | impl<'a> IntoIterator for &S {
| ^^ unconstrained lifetime parameter
|
help: consider using the named lifetime here instead of an implict lifetime
|
LL | impl<'a> IntoIterator for &'a S {
| ++
```
When an associated type is missing a lifetime, point at its enclosing `impl`, whether it has or doesn't have lifetimes defined. If it does have a lifetime, suggest using it.
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-1.rs:8:17
|
LL | impl<'a> IntoIterator for &S {
| ---- there is a named lifetime specified on the impl block you could use
...
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
|
help: consider using the lifetime from the impl block
|
LL | type Item = &'a T;
| ++
```
```
error: in the trait associated type is declared without lifetime parameters, so using a borrowed type for them requires that lifetime to come from the implemented type
--> $DIR/missing-lifetime-in-assoc-type-2.rs:5:17
|
LL | impl IntoIterator for &S {
| - you could add a lifetime on the impl block, if the trait or the self type can have one
LL | type Item = &T;
| ^ this lifetime must come from the implemented type
```
```
error[E0277]: the trait bound `[[u16; 3]; 2]: Bar` is not satisfied
--> $DIR/issue-67185-2.rs:21:6
|
LL | impl Foo for FooImpl {}
| ^^^ the trait `Bar` is not implemented for `[[u16; 3]; 2]`
|
help: the following other types implement trait `Bar`
--> $DIR/issue-67185-2.rs:9:1
|
LL | impl Bar for [u16; 4] {}
| ^^^^^^^^^^^^^^^^^^^^^ `[u16; 4]`
LL | impl Bar for [[u16; 3]; 3] {}
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ `[[u16; 3]; 3]`
note: required by a bound in `Foo`
--> $DIR/issue-67185-2.rs:14:30
|
LL | trait Foo
| --- required by a bound in this trait
LL | where
LL | [<u8 as Baz>::Quaks; 2]: Bar,
| ^^^ required by this bound in `Foo`
```
```
error[E0277]: the trait bound `u32: Trait` is not satisfied
--> $DIR/trait_objects_fail.rs:26:9
|
LL | foo(&10_u32);
| ^^^^^^^ the trait `Trait` is not implemented for `u32`
|
help: the trait `Trait<12>` is not implemented for `u32`
but trait `Trait<2>` is implemented for it
--> $DIR/trait_objects_fail.rs:7:1
|
LL | impl Trait<2> for u32 {}
| ^^^^^^^^^^^^^^^^^^^^^
= note: required for the cast from `&u32` to `&dyn Trait`
```
Pointing at the `impl` definition that *could* apply given a different self type is particularly useful when it has a blanket self type, as it might not be obvious and is not trivially greppable:
```
error[E0277]: the trait bound `RawImpl<_>: Raw<_>` is not satisfied
--> $DIR/issue-62742.rs:4:5
|
LL | WrongImpl::foo(0i32);
| ^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Raw<_>` is not implemented for `RawImpl<_>`
but trait `Raw<[_]>` is implemented for it
--> $DIR/issue-62742.rs:29:1
|
LL | impl<T> Raw<[T]> for RawImpl<T> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: required by a bound in `SafeImpl`
--> $DIR/issue-62742.rs:33:35
|
LL | pub struct SafeImpl<T: ?Sized, A: Raw<T>>(PhantomData<(A, T)>);
| ^^^^^^ required by this bound in `SafeImpl`
```
Since non-poisoning `Condvar` take non-poisoing `Mutex`es when
`wait`ing, we do not need to take by ownership since a poison error
cannot occur while we wait.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Setup for writing different tests for the `nonpoison::Condvar` since it
will have a different API.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
