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.
|
so, cc @maxdexh @theemathas - do you suspect there will be significantly more soundness bugs to iron out on the core traits? i'd lightly push towards landing this on nightly soonish and adjusting stuff in followup PRs. in the same spirit, i ditched |
|
I think the feature is in a great state now, thanks for the awesome work :D I'll be giving the safety requirements another read and will try to break it again when I get time at the end of next week, but I'm pretty happy with how the API looks right now (and glad that it wasn't stabilized in the old state 😅) Also if this hits nightly it'll be much easier to work with for me as well, so I'm strongly in favor of that. |
|
Did you plan to add the |
|
Other than the opsem stuff (which I haven't been following at all and therefore don't know the state of), and btree stuff (which is a later problem), I don't think there are other soundness issues. I'll probably have a few more looks at it before stabilization though. |
i'd leave that for the PR that actually moves the allocator out of the arc, which would be a blocker for stabilising anything like |
Such a PR will probably be blocked by all the other changes being made to But it's fine if the allocator generic on |
|
the plan is for everything allocator-y about Rc and Arc to stay unstable for now, no worries ^^ |
|
Institutional knowledge yay |
|
see the stabilisation doc on the main stabilisation PR (deets somewhat out of date now, but the plan for what to stabilise hasn't been changed) - i've been trying to avoid making too much of this institutional knowledge :D |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been minimized.
This comment has been minimized.
|
For the record, |
|
please do file issues for everything distinct! we need to keep track of what's outstanding as we go and stabilise things |
This comment was marked as off-topic.
This comment was marked as off-topic.
Which opsem stuff? There should be none left since we delegated all opsem magic to a hypothetical future And there's the unleaking problem but not much we can do about that, that just is fundamentally a tricky footgun. |
|
(Have been mostly just waiting for the discussion to settle before doing a proper review, and poking at random simple changes to the code where they don't require much thinking to verify they're correct.) |
| @@ -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 😅
View all comments
Adds my current proposal per the doc in #156882 and follow-up Zulip conversations (notably for dyn-compat) unstably.
r? libs