[zannabianca1997]

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

• get the feature gate into main (Move trait feature gate #165569)
• Fix rustdoc handling
• Look into diesel regression

r? jdonszelmann

[rustbot]

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]

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]

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]

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]

@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]

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

[zannabianca1997]

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

[fmease]

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.

[fmease]

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.

[zannabianca1997]

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

[rustbot]

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

[zannabianca1997]

Tests done - with the only exception of a single one regarding the reflection api (#146922, in particular #151239) that's broken by everything now having a + Move

@jdonszelmann i put a patch for diesel - plainly stripping Move from the bounds when the feature is not in. Locally perf is good (~1%) but I would run it again

[rust-log-analyzer]

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' (19263) panicked at library/coretests/tests/mem/type_info.rs:360:9:
assertion `left == right` failed: unexpected ids.
actual: [TypeId(0x803862e84c23c9c0186b8480665917c0), TypeId(0x7295e9096c1a47b3ef4a2911cfb1c694)]
expected: [TypeId(0x0be30bda9f7763c8fd87c962437454e0)]
  left: {TypeId(0x803862e84c23c9c0186b8480665917c0), TypeId(0x7295e9096c1a47b3ef4a2911cfb1c694)}
 right: {TypeId(0x0be30bda9f7763c8fd87c962437454e0)}
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.