-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Clarify that copied allocators must behave the same #105096
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
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
r? libs-api |
@bors r+ rollup |
@rustbot label +T-libs-api -T-libs (just for consistency's sake) |
☀️ Test successful - checks-actions |
Finished benchmarking commit (48ae1b3): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Currently, the safety documentation for
Allocator
says that a cloned or moved allocator must behave the same as the original. However, it does not specify that a copied allocator must behave the same, and it's possible to construct an allocator that permits being moved or cloned, but sometimes produces a new allocator when copied.Contrived example which results in a Miri error
This could result in issues in the future for algorithms that specialize on
Copy
types. Right now, nothing in the standard library that depends onAllocator + Clone
is susceptible to this issue, but I still think it would make sense to specify that copying an allocator is always as valid as cloning it.