Make the public API of the alloc crate a subset of std#51569
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #51543) made this pull request unmergeable. Please resolve the merge conflicts. |
|
r? @sfackler |
|
Also rewrote the paragraph in the crate’s doc-comment that said “not intended for general usage” to instead mention |
|
☔ The latest upstream changes (presumably #50357) made this pull request unmergeable. Please resolve the merge conflicts. |
This matches std::collections
… since `std` has no corresponding reexports. Use `alloc::vec::Vec` and `alloc::string::String` instead.
|
Rebased. |
|
@bors r+ |
|
📌 Commit 15bb6c4 has been approved by |
bors
added
S-waiting-on-bors
Make the public API of the alloc crate a subset of std This only affects **unstable** APIs. I plan to submit an RFC proposing to stabilize the crate. The reason it isn’t stable yet (#27783) is in case we end up merging the standard library crates into one. However the `core` crate is already stable, so if that happens we’ll need to keep it working somehow (likely by making replacing its contents by `pub use` items). We can do the same for `alloc`. This PR will hopefully make this easier, but even if that doesn’t happen consistency with `std` seems good.
|
☀️ Test successful - status-appveyor, status-travis |
|
📣 Toolstate changed by #51569! Tested on commit 2c1a715. 💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). |
Tested on commit rust-lang/rust@2c1a715. Direct link to PR: <rust-lang/rust#51569> 💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rustfmt on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra). 💔 rustfmt on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).
5 participants
This only affects unstable APIs.
I plan to submit an RFC proposing to stabilize the crate. The reason it isn’t stable yet (#27783) is in case we end up merging the standard library crates into one. However the
corecrate is already stable, so if that happens we’ll need to keep it working somehow (likely by making replacing its contents bypub useitems). We can do the same foralloc. This PR will hopefully make this easier, but even if that doesn’t happen consistency withstdseems good.