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