Remove uses of last-use analysis #3754
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Had to remove the buffalo example. It was awkward to update for explicit moves.
...they require copying noncopyable fields.
and require explicit moves. Also provide more info in some error messages. Also: check that non-copyable struct fields don't get copied. Closes rust-lang#3481
|
r+ |
|
One thought: to avoid errors with inconsistent messages (like "Try adding a move"), you could use a |
bors
pushed a commit
to rust-lang-ci/rust
that referenced
this pull request
May 15, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request removes the reliance of kind checking and trans on last-use analysis. This means two main things:
There is also one separate change (I know, I know) which is to change the kind checker to make struct fields non-copyable as per #3481.
Only 9abc7f0 , c4155f5, and c6780fb need any review. The other patches are mostly just inserting implicit moves.
I had said that these patches caused a performance regression, but on further investigation, it doesn't. Either the performance hit comes from code I already checked in long ago (adding explicit moves), or -- more likely -- I was comparing between optimized and unoptimized builds :-( So I'm pretty confident that merging this pull request won't harm performance significantly.
I know we are potentially going to implement @nmatsakis's type-based move proposal, but in the meantime, this work is done and we might as well merge it to avoid the problems described in #2633.