Use AllocRef for ZSTs in RawVec#69824
Conversation
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
a2679ba to
2c8c689
Compare
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
@Gankra Do you want to take a look into this, as you have written the first |
|
I probably want to merge rust-lang/wg-allocators#44 first as well, as |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
My main concern with this change is that we are turning a compile-time check ( |
|
AFAICT we don't have that runtime check. Let's take
We basically just move the checks one layer down the road. When using Hopefully I didn't miss anything there... 😄 |
|
☔ The latest upstream changes (presumably #69879) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Closing in favor of #69889 |
Moves the responsibility for handling ZSTs from
RawVectoAllocRef. On the same occasion I have moved the logic for reserving and shrinking into the new methodsgrowandshrinkto keep the logic in one place without changing the behavior.Every grow/shrink operation now has three steps:
AllocRefself.ptrandself.capThere are no more checks in
RawVecneeded for taking a different path for ZSTs.This is the last item on the roadmap to support ZSTs in
AllocRef: rust-lang/wg-allocators#38 (comment)Requires #69799 to land first, otherwise
Globalwill be called with zero-sized layouts.closes rust-lang/wg-allocators#38
r? @Amanieu