`Move` trait prototype by zannabianca1997 · Pull Request #161457 · rust-lang/rust

zannabianca1997 · 2026-08-21T12:23:02Z

Finishing the work started by @nia-e in #156018 :

Add a barebones implementation for Move (#149607), pending some diagnostics changes & tests.

TODO

next solver currently errors when not enabling feature(move_trait)
change printing of trait objects to not show Move
change printing of opaque types to not show Move
fix mangling of Move bounds
how to handle empty trait object that now are dyn Move
relationship between PhantomData<T>: Move and T: Move
also make sure rustdoc handles move correctly
valuable to look into why diesel regresses

r? lcnr

rustbot · 2026-08-21T12:23:08Z

Thanks for the pull request, and welcome! The Rust Project has assigned @lcnr (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions for more information.

zannabianca1997 · 2026-08-21T19:11:02Z

A quick ./x.py test tests/ui locally to have a baseline

test result: FAILED. 9 passed; 206 failed; 21862 ignored; 0 measured; 0 filtered out; finished in 1.14s

zannabianca1997 · 2026-08-21T21:14:12Z

test result: FAILED. 21801 passed; 32 failed; 244 ignored; 0 measured; 0 filtered out; finished in 168.70s

wow that were a lot of them. looks like the next batch is a bunch of fn that now has fn() + Move

zannabianca1997 · 2026-08-22T13:40:24Z

looking at the errors, there is also a bunch of (dyn + 'static) printing.

Those are all checks going around the trait_alias feature, that created before empty trait object and now creates what are effectively dyn Move, that are being misprinted.

That sure raises a question - can we handle them now? ummm - putting this aside in favour of lower hanging fruits

zannabianca1997 · 2026-08-22T18:13:58Z

@lcnr this last one (520bc2f)

it's better to break the ABI and accept all aymbol mangling containing Move or we have to decide a way to mangle ?Move? I know rust has no stable abi but to put it in all symbols seems a bit too much

lcnr · 2026-08-28T13:37:21Z

+            .collect()
+    } else {
+        clauses.into_iter().collect()
+    };


that one is unfortunately somewhat problematic. gather_explicit_clauses_of is used by a query whose result we write to crate metadata, so this would erase the Move bound from upstream crates which don't have the feature enabled.

Why is this needed

View changes since the review

Of the changes that I made this is the one i was less sure of

I was trying to fix this test

The original test expected

error[E0091]: type parameter `N` is never used --> $DIR/unused-type-param-suggestion.rs:25:8 | LL | type D<N: ?Sized> = (); | ^ unused type parameter | = help: consider removing `N` or referring to it in the body of the type alias

and after the change with Move it appeared a new help message = help: if you intended Nto be a const parameter, useconst N: /* Type */ instead

now, the help should not appear as there is a bound - so i checked from where it came, and got to read the check_type_alias_type_params_are_used that uses some sort of euristic to split huser written bounds and the sized hierarchy (?)

I honestly lost the plot there, but noticed that it was calling the _explicit_ version. And I saw the doc comment of gather_explicit_clauses_of noting that implied and inferred constraints should not appear there, and Move is indeed implicit in that case, so I just aligned it

And I saw the doc comment of gather_explicit_clauses_of noting that implied and inferred constraints should not appear there, and Move is indeed implicit in that case, so I just aligned it

Default bounds (or what this PR now also calls "implicit bounds") are excluded from that. Without knowing all the places where we'll perform Move elaboration I would probably revert that.

The comment on gather_explicit_clauses_of doesn't consider these bounds to be potential implied bounds (in the sense of implied supertrait bounds, implicit outlives-bounds, etc.). You can see that gather_explicit_clauses_of does elaborate sizedness & other default bounds.

That's because default bounds plus relaxed bounds are just considered syntax sugar / an early syntactic transformation.

now, the help should not appear as there is a bound - so i checked from where it came, and got to read the check_type_alias_type_params_are_used that uses some sort of euristic to split huser written bounds and the sized hierarchy (?)

Regarding the heuristic, it utilizes the fact that implicitly added Sized (etc.) bounds have the same span as the type parameter they annotate (in order to identify which bounds to "count").

So for (pseudo) <T>, the span of the implicit T: Sized is identical to the span of type parameter T. The span that's used comes from explicit_clauses_of / gather_explicit_clauses_of.

I would check what the span we use for implicit T: Move bounds (T type param). If it indeed shares the span with the type param, then there must be something else going on.

Okkkkkkkk

managed to find the correct solution!

it was a fixme that needed handling at the time (cause spans for different lines were not able to be merged

so yeah. now it works with c372a25

mostly to avoid adding to every single dynamic symbol the `+ Move`

the output uses the debug print and parses it with regex fixed the regex to fetch the first trait, instead of Move

I am _almost_ sure this is what nia wanted to write. I am modifying the behaviour, but I don't see how should it be different, as Move enters now the implicit trait group

missing

…eature is" This reverts commit eda1c34.

handled Move as an additional bound instead of removing it from the gathered explicit clauses addressed an old FIXME that gave me the direction reverted the changes of a couple of tests that now see the Move

Again, not very sure of this. I don't really know the itanium c++ stuff, but looks like Send and Sync are there so it should contains it? And removing it in favour of `?Move` makes a ton of other tests fail. So I guess i'll let it like this and let it breaks later if it does

rust-log-analyzer · 2026-10-05T14:12:01Z

The job test-x86_64-gnu-gcc-core-tests failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- mem::type_info::test_dynamic_traits stdout ----
---- mem::type_info::test_dynamic_traits stderr ----

thread 'main' (19063) panicked at library/coretests/tests/mem/type_info.rs:360:9:
assertion `left == right` failed: unexpected ids.
actual: [TypeId(0x13229e2c6c9e8bfccd8b7a2549f049d8), TypeId(0xe9f33906dd2bbb0afc41fff307c3b2de)]
expected: [TypeId(0x5506557cbc0cdd581706b10f68f7634a)]
  left: {TypeId(0xe9f33906dd2bbb0afc41fff307c3b2de), TypeId(0x13229e2c6c9e8bfccd8b7a2549f049d8)}
 right: {TypeId(0x5506557cbc0cdd581706b10f68f7634a)}
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
---- mem::type_info::test_dynamic_traits stdout end ----

failures:
    mem::type_info::test_dynamic_traits

Important

For more information how to resolve CI failures of this job, visit this link.

rust-bors · 2026-10-08T10:25:54Z

☔ The latest upstream changes (presumably #163970) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

rustbot assigned lcnr Aug 21, 2026