Move trait prototype

[zannabianca1997]

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
• also make sure rustdoc handles move correctly
• valuable to look into why diesel regresses

r? lcnr

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

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)*

[zannabianca1997]

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

[zannabianca1997]

done u.u

[lcnr]

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)*

[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