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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
reuse RHS allocation for vec.extend(vec.into_iter()) when they do not fit into the LHS #77496
reuse RHS allocation for vec.extend(vec.into_iter()) when they do not fit into the LHS #77496
Changes from 3 commits
c5af975
2409653
8a0a13a
0c443cf
153a916
cb477d4
5e6abf1
567cd52
1dbab48
aa4a4ac
1885f38
d460c85
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be simplified as?
I wonder if this will always grow the vec if the iterator is larger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposed change would underflow if self is larger than iterator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Underflow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is technically still an overflow, but that
iterator.len() - self.len()
would panic or wrap if, say,self.capacity() == 20_000
andself.len() == 19_950
, anditerator.len() == 100
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant the case where
self.capacity() > iterator.cap
. The subtraction would underflow theusize
result and thus lead to the inequality unexpectedly evaluating totrue
which would then violate the safety constraints ofinto_vec_with_uninit_prefix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then how about?
I
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For a self with
len == 2 && cap == 2
and an iteratorlen == 2 && cap == 3
that would evaluate to true and attempt to store 4 elements into an allocation of 3. 💣💥There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we turn this into an
else
block instead of early returning?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can, but I prefer early returns since the later part indicates the default approach in contrast to the special case above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mentioned the same thing above #77496 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find splitting the branches here a bit easier to follow so you can tell that there's two paths we can take and don't have any way to fall through this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could probably use
add
instead ofoffset
forusize
, but I don't know if the compiler will optimize out theoffset
if it is0
? Does it or should we have two functions, one with offset and one without?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0 is a constant in the other callsite, so it should be easy to optimize for llvm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @lzutao to see if he's interested to check this out