Repository navigation
Move trait prototype - #161457
Move trait prototype#161457zannabianca1997 wants to merge 38 commits into
Move trait prototype#161457Conversation
|
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. |
This comment has been minimized.
This comment has been minimized.
|
A quick |
wow that were a lot of them. looks like the next batch is a bunch of |
This comment has been minimized.
This comment has been minimized.
|
looking at the errors, there is also a bunch of Those are all checks going around the That sure raises a question - can we handle them now? ummm - putting this aside in favour of lower hanging fruits |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
33dfdac to
30609e6
Compare
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.
This comment has been minimized.
| .collect() | ||
| } else { | ||
| clauses.into_iter().collect() | ||
| }; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
And I saw the doc comment of
gather_explicit_clauses_ofnoting that implied and inferred constraints should not appear there, andMoveis 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.
There was a problem hiding this comment.
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_usedthat 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.
There was a problem hiding this comment.
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
This comment has been minimized.
This comment has been minimized.
429ec3c to
a068654
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
0acfa71 to
c51c5c0
Compare
…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
made the test ordering-agnostic. There is a FIXME - should check that
396bbda to
9c34ac9
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
… r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
Rollup merge of #165374 - jdonszelmann:move-trait-splitouts, r=ShoyuVanilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
…anilla Refactorings in preparation for the move trait r? project-trait-system-refactor This does a couple of innocent refactorings that are necessary *both* for Forget and Move. By merging it, both the `Move` trait pr (rust-lang/rust#161457) and work on the Forget trait can continue without conflicts, and when reviewing them, these refactorings don't need to be considered again. > [!NOTE] > I've not used an LLM for any part of this PR, or any other PR I make. This includes any related work like research.
View all comments
Finishing the work started by @nia-e in #156018 :
TODO
feature(move_trait)MoveMoveMoveboundsdyn MovePhantomData<T>: MoveandT: Movedieselregressesr? lcnr