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

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

View all comments

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

it should give some info tho...

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

Oh wow that got done with A LOT of tests

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

This is one of the two options, the other being break ABI. I suspect we can do it, Rust not having a stable one (?)

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

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

missing

lcnr · 2026-08-28T13:31:54Z


        // We don't support empty trait objects.
-        if regular_traits.is_empty() && auto_traits.is_empty() {
+        if regular_traits.iter().all(|t| tcx.is_implicit_trait(t.0.skip_binder().def_id(), false))


hmm, feel like this can just be regular_traits.chain(auto_traits).all(is_implicit_trait)

also existing, but can you replace the bool of is_implicit_trait wth an enum, e.g.

enum WhateverThisfunctionwants { Yes, No, } *[View changes since the review](https://triagebot.infra.rust-lang.org/gh-changes-since/rust-lang/rust/161457/9a4ad59ae3073b013cd62f53f8349ddc61a012e8..5a6f61532811493d3a1fd88aecf71ce42594ec2e)*

Ops, wanted to clean that up but forgot. Will do. Also yeah, that would make much sense in readability. I can see it being extended in the future so will probably be more beneficial after

lcnr · 2026-08-28T13:34:40Z

                write!(self, " + ")?;
            }
+            first = false;
            write!(self, "PointeeSized")?;


do we want somethign like... we do repeat this pattern a lot

let mut first = false; let mut print_bound = |bound| { if !first { write!(self, " + ")?; first = false; } self.write_str(bound) }; *[View changes since the review](https://triagebot.infra.rust-lang.org/gh-changes-since/rust-lang/rust/161457/9a4ad59ae3073b013cd62f53f8349ddc61a012e8..5a6f61532811493d3a1fd88aecf71ce42594ec2e)*

Addressed - there are probably a ton of other similar cases of sparse printing with a separator, so i just wrote a helper struct to make code cleaner

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

…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

rust-log-analyzer · 2026-09-02T21:57:07Z

The job 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' (18873) panicked at library/coretests/tests/mem/type_info.rs:364:9:
assertion `left == right` failed: unexpected ids.
actual: [TypeId(0x8a0825f6ff8bb6933ece377a9b54ce97), TypeId(0x526af8801a242c205ceb6eb017f4ebe0)]
expected: [TypeId(0xa55981b3256cbfe53d06dbf32f61ccc1)]
  left: {TypeId(0x8a0825f6ff8bb6933ece377a9b54ce97), TypeId(0x526af8801a242c205ceb6eb017f4ebe0)}
 right: {TypeId(0xa55981b3256cbfe53d06dbf32f61ccc1)}
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.

cramertj · 2026-09-02T22:26:32Z

+        {T: PointeeSized + ?Move} *mut T,
+        {T: PointeeSized + ?Move} &T,
+        {T: PointeeSized + ?Move} &mut T,
+        {T: PointeeSized + ?Move} PhantomData<T>,


Apologies for the drive-by, but it's surprising to me that PhantomData would unconditionally implement Move, rather than implementing it only when T: Move. Other marker trait impls for PhantomData are conditional on T: https://doc.rust-lang.org/std/marker/struct.PhantomData.html#synthetic-implementations

View changes since the review

ummm...

I often saw phantomdata as a way to maintain pointer type info, so having &'a T be somewhat equivalent to (*const (), PhantomData<&'a T>). Wouldn't not implementing Move for it make this kind of pointers immovable? The moveability of the pointer should not be related to the one of the pointee

generally I see in the future a proliferation of Phantom* types (like #135806) to represent different aspects you want to inherit from the type

lcnr · 2026-09-03T10:40:04Z

+        result.clauses = tcx.arena.alloc_from_iter(result.clauses.iter().copied().filter(|p| {
+            !p.0.as_trait_clause().is_some_and(|p| {
+                p.polarity() == ClausePolarity::Positive
+                    && matches!(tcx.as_lang_item(p.def_id()), Some(LangItem::Move))


for perf reasons, it might actually be faster to do

if !tcx.features().move_trait() { let move_trait = tcx.get_lang_item(LangItem::Move); // filter_by_comparing to that :> }

might be worth another perf run with that change 😁

View changes since the review

lcnr · 2026-09-03T10:40:31Z

                    hir_bounds,
                    ImpliedBoundsContext::AssociatedTypeOrImplTrait,
                    span,
+                    true,


that bool should also be a newtype enum 🤣 no clue what it means without looking at the function definition

View changes since the review

nia-e and others added 4 commits June 15, 2026 16:08

fallible type ops

cc87a4e

move trait

2a3042b

Fix: removed Move from being printed at all

bde0cb3

it should give some info tho...

Fix: assume Move when the move_trait feature is not added

f5a5e65

rustbot assigned lcnr Aug 21, 2026

This comment has been minimized.

Sign in to view

lcnr mentioned this pull request Aug 21, 2026

implement Move trait prototype #156018

Closed

3 tasks

lcnr changed the title ~~Move trait prototype~~ Move trait prototype Aug 21, 2026

Fix: preferred printing of ?Move instead of Move

acbf9e8

Oh wow that got done with A LOT of tests

This comment has been minimized.

Sign in to view

Feat: removed Move from mangled symbols

f028f7b

This is one of the two options, the other being break ABI. I suspect we can do it, Rust not having a stable one (?)

This comment has been minimized.

Sign in to view

zannabianca1997 added 4 commits August 23, 2026 14:00

Feat: mangling of ?Move bounds

d319d8e

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

Fix: legacy mangler (Fn printer)

ab882e1

Fix: normalized test

b2cb667

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

Fix: correctly refusing trait objects that have only Move as a bound

e5b038d

zannabianca1997 force-pushed the move-trait branch from 33dfdac to 30609e6 Compare August 23, 2026 19:01

Fix: line number drift

ed155b9

This comment has been minimized.

Sign in to view

Fix: removed the move clause from explicit clauses when the feature is

eda1c34

missing

This comment has been minimized.

Sign in to view

lcnr reviewed Aug 28, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

zannabianca1997 added 9 commits August 28, 2026 22:12

Cleanup

6d17593

Fix: expanded boolean into a more comprehensible enum

dc150f7

aligned to boolean values

b1dec32

Fix: helper to avoid repeating printing pattern

6bcca4c

Fix: missing prints

b70a71b

reborrow! yay.

830a27b

Fix: documented error in feature gate test

5e5cb73

Fix: documented test being fixed under the next solver

19397e8

Chore: new test use the debug too

309e68d

zannabianca1997 force-pushed the move-trait branch from 429ec3c to a068654 Compare August 30, 2026 13:12

This comment has been minimized.

Sign in to view

Giving up for now on aligning winnowing of Move to Sized

c51c5c0

zannabianca1997 force-pushed the move-trait branch 2 times, most recently from 0acfa71 to c51c5c0 Compare September 2, 2026 18:04

This comment has been minimized.

Sign in to view

zannabianca1997 added 2 commits September 2, 2026 20:39

Revert "Fix: removed the move clause from explicit clauses when the f…

2df83aa

…eature is" This reverts commit eda1c34.

Fix: addressed fixme

c372a25

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

cramertj reviewed Sep 2, 2026

View reviewed changes

lcnr reviewed Sep 3, 2026

View reviewed changes

lcnr mentioned this pull request Sep 3, 2026

Immobile types and guaranteed destructors rust-lang/goals#635

Open

Uh oh!

Uh oh!

Conversation

zannabianca1997 commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODO

Uh oh!

rustbot commented Aug 21, 2026

Uh oh!

This comment has been minimized.

zannabianca1997 commented Aug 21, 2026

Uh oh!

zannabianca1997 commented Aug 21, 2026

Uh oh!

This comment has been minimized.

zannabianca1997 commented Aug 22, 2026

Uh oh!

zannabianca1997 commented Aug 22, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

lcnr Aug 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

lcnr Aug 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Aug 29, 2026

Choose a reason for hiding this comment

Uh oh!

lcnr Aug 28, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Aug 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Aug 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Sep 2, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rust-log-analyzer commented Sep 2, 2026

Uh oh!

cramertj Sep 2, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

lcnr Sep 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zannabianca1997 commented Aug 21, 2026 •

edited

Loading

lcnr Aug 28, 2026 •

edited by rustbot

Loading

lcnr Aug 28, 2026 •

edited by rustbot

Loading

lcnr Aug 28, 2026 •

edited by rustbot

Loading

zannabianca1997 Aug 28, 2026 •

edited

Loading

fmease Aug 30, 2026 •

edited

Loading

fmease Aug 30, 2026 •

edited

Loading

cramertj Sep 2, 2026 •

edited by rustbot

Loading

lcnr Sep 3, 2026 •

edited by rustbot

Loading

lcnr Sep 3, 2026 •

edited by rustbot

Loading