allocator: refactor for stabilisation - #157428
Conversation
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.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@rustbot author (mostly so you can more clearly signal when you think things are ready; I've commented here already so I'll see any additional changes for review as they're made) |
This comment has been minimized.
This comment has been minimized.
| @@ -74,7 +74,8 @@ impl fmt::Display for AllocError { | |||
| /// * Moving, subtyping, unsize-coercing, or trait-upcasting an allocator does not change | |||
| /// what the allocator is equivalent to. | |||
| /// * Copying or cloning allocator results in an allocator that's | |||
There was a problem hiding this comment.
Do we require copies to be equivalent? If so, this relies on the orphan rule for Copy (which might be fine since Copy is special), but I'm confused because the AllocatorClone docs do not talk about requirements for copies.
There was a problem hiding this comment.
I thought there was wording to the effect of "if Copy could be implemented for an AllocatorClone type, that must also obey its semantics", but if not I will add it. ty!
There was a problem hiding this comment.
What do you mean by "could"? Can we rely on Drop + Copy being disallowed for soundness? I think we didn't discuss this part enough 😅
This comment has been minimized.
This comment has been minimized.
a41958f to
acb148f
Compare
This comment has been minimized.
This comment has been minimized.
|
(apologies for the squash-and-rebase, nothing meaningful to review should have changed between force-pushes) |
This comment has been minimized.
This comment has been minimized.
| if self.len() > source.len() { | ||
| self.split_off(source.len()); | ||
| } | ||
| for (elem, source_elem) in self.iter_mut().zip(&mut source_iter) { | ||
| for elem in self.iter_mut() { | ||
| let Some(source_elem) = source_iter.next() else { | ||
| break; | ||
| }; | ||
| elem.clone_from(source_elem); | ||
| } | ||
| while self.len() > source.len() { | ||
| self.pop_back(); | ||
| } |
There was a problem hiding this comment.
Unreasonably upset at this code just because of how limited the LinkedList API is. Should be doable, but isn't… :(
|
This PR seems to make multiple unrelated changes. Is it possible to get an overview of all the changes it's making? Or even better, perhaps we could split out this into multiple PRs so that we can merge the things we agree on now, without blocking them on the things still being discussed? |
|
I'm unsure how i'd go about splitting this up, since many of the miscellaneous library changes are necessary for the API to be sound. (ofc, if you have an idea that'd lighten the review burden, i'm happy to do it and i think @clarfonthey would be relieved too) In short, the changes made are:
i'm quite happy with the fact that (beyond adding the ban on unwinding out of an allocating method or drop) none of this tightens requirements on |
|
Also, unlike the old allocator api, we think this is sound (modulo some details in the docs we haven't discussed fully) :D |
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.
yk what we can do btree later raaaaagh pain and suffering *unleaks your box* whats thiSegmentation fault (core dumped) straight up testing it. and by it, well, let's just say. "my allocator" linked and listed the unnecesary bits? gone. reduced to atoms
791e139 to
f4d4ee7
Compare
|
This PR was rebased onto a different main 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. |
|
(squashed & rebased since #56935 conflicted; only change was renaming |
View all comments
Adds my current proposal per the doc in #156882 and follow-up Zulip conversations (notably for dyn-compat) unstably.
r? libs