Add Vec<T> into Arc/Rc<[T]> lint#16790
Conversation
|
r? @dswij rustbot has assigned @dswij. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Lintcheck changes for a6eec8f
This comment will be updated if you push new changes |
7e67b53 to
fac19f9
Compare
|
the changelog message doesn't need to be enclosed in a code block:) I think the default PR comment is confusing people into thinking that, because you're not the first one to have done this^^ |
|
Reminder, once the PR becomes ready for a review, use |
fac19f9 to
5d5596e
Compare
|
@rustbot ready I use |
Hello fellow jj user:) I mean force-pushing is usually okay if you're only addressing smaller comments, but yeah in this case a separate commit would've been nice. Oh well^^ |
|
@rustbot author |
|
@rustbot ready |
This comment has been minimized.
This comment has been minimized.
|
@rustbot ready @ada4a I ended up not rolling back the ascryption change. I think you're right it's a losing battle but the context I have it in working with atm is probably still useful. Sorry for the delay on this. I also noted the conflict -- I'll wait until this is approved to avoid the force push. |
Oh don't worry, that should be fine -- when you do a rebase, rustbot shows this nice range-diff thing, which hides the "all the new stuff from main" part of the changes and allows concentrating on the "the things that the rebase changed in this PR" part.
That's no problem either:) As you can see, I'm not perfect myself^^ In general you're more likely to need to wait for a reviewer than vice versa... |
Adds a lint detecting conversions from `Vec<T>` into `Arc<[T]>` and `Rc<[T]>`. When doing this conversion, the source `Vec<T>` allocation cannot be re-used because of incompatible layout with `Arc<[T]>` and `Rc<[T]>`, which may be a fairly expensive reallocation depending on the source vector's size. In most cases, it's probably better to convert to an `Arc<Box<[T]>>` instead. See discussion here for rationale: https://users.rust-lang.org/t/could-arc-t-from-vec-t-be-optimized-to-remove-the-copy/137532
e79c36a to
41904d2
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@rustbot ready |
|
This lint has been nominated for inclusion. |
|
☔ The latest upstream changes (possibly #16025) made this pull request unmergeable. Please resolve the merge conflicts. |
View all comments
.stderrfile)cargo testpasses locallycargo dev update_lintscargo dev fmtAdds a lint detecting conversions from
Vec<T>intoArc<[T]>andRc<[T]>. When doing this conversion, the sourceVec<T>allocation cannot be re-used because of incompatible layout withArc<[T]>andRc<[T]>, which may be a fairly expensive reallocation depending on the source vector's size.In most cases, it's probably better to convert to an
Arc<Box<[T]>>instead.See discussion here for rationale: https://users.rust-lang.org/t/could-arc-t-from-vec-t-be-optimized-to-remove-the-copy/137532
changelog: [
vec_to_rc_slice]: add perf lint for converting fromVec<[T]>toArc<[T]>/Rc<[T]>