Remove the `alloc_system` crate #55660

alexcrichton · 2018-11-03T18:34:39Z

In what's hopefully one of the final nails in the coffin of the "old allocator story of yore" this PR deletes the alloc_system crate and all traces of it from the compiler. The compiler no longer needs to inject allocator crates anywhere and the alloc_system crate has no real reason to exist outside the standard library.

The unstable alloc_system crate is folded directly into the standard library where its stable interface, the System type, remains the same. All unstable traces of alloc_system are removed, however.

rust-highfive · 2018-11-03T18:34:48Z

r? @dtolnay

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2018-11-03T18:35:51Z

src/librustc_asan/lib.rs

-use alloc_system::System;
-
-#[global_allocator]
-static ALLOC: System = System;


Note that this and the other sanitizer crates no longer link to System as it's not an available type to use. While a regression I think this is minor enough to allow because the default allocator is now System (not jemalloc) which all the sanitizers are compatible that. That, plus the fact that the sanitizers are unstable

kevinmehall · 2018-11-03T19:23:52Z

src/libstd/alloc.rs

+/// This type can be used in a `static` item
+/// with the `#[global_allocator]` attribute
+/// to force the global allocator to be the system’s one.
+/// (The default is jemalloc for executables, on some platforms.)


Do you want to update this doc comment while you're moving it?

dtolnay · 2018-11-03T23:59:34Z

Looks good to me but let's run this by @SimonSapin as well:

r? @SimonSapin

SimonSapin · 2018-11-04T00:13:11Z

Looks good to me as well, with the doc-comment for System updated as @kevinmehall pointed out.

It probably doesn’t make sense anymore to show a #[global_allocator] static A: System = System; example. Maybe replace it with an example that uses GlobalAlloc::alloc?

mattico · 2018-11-04T22:40:53Z

src/librustc_metadata/creader.rs

            self.sess.allocator_kind.set(None);
            return
        }

        // At this point we've determined that we need an allocator. Let's see
        // if our compilation session actually needs an allocator based on what
        // we're emitting.
-        let mut need_lib_alloc = false;
-        let mut need_exe_alloc = false;
+        let mut all_rlib = true;
        for ct in self.sess.crate_types.borrow().iter() {


Nit: this could be let all_rlib = self.sess.crate_types.borrow().iter().all(|ct| *ct == config::CrateType::Rlib)

alexcrichton · 2018-11-05T16:04:29Z

@bors: r=dtolnay,SimonSapin

bors · 2018-11-05T16:04:31Z

📌 Commit 7fa5adfb6cbe5f222f092fbec429e7ce40d01a57 has been approved by dtolnay,SimonSapin

bors · 2018-11-06T06:59:51Z

☔ The latest upstream changes (presumably #55518) made this pull request unmergeable. Please resolve the merge conflicts.

alexcrichton · 2018-11-06T15:11:58Z

@bors: r=dtolnay,SimonSapin

bors · 2018-11-06T15:12:00Z

📌 Commit 1116d6e0f46fa4b8fb15c606764d429351a4271e has been approved by dtolnay,SimonSapin

sfackler · 2018-11-06T17:04:50Z

cc @frewsxcv for the sanitizer implications

frewsxcv · 2018-11-10T15:28:29Z

cc @frewsxcv for the sanitizer implications

What are the sanitizer implications of this?

bors · 2018-11-11T12:09:59Z

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

git checkout cleanup-alloc-system (switch to your branch)
git fetch upstream master (retrieve the latest master)
git rebase upstream/master -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
git push self cleanup-alloc-system --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

warning: Cannot merge binary files: src/Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/libstd/lib.rs
Auto-merging src/librustc/session/mod.rs
Removing src/liballoc_system/lib.rs
Removing src/liballoc_system/Cargo.toml
Auto-merging src/Cargo.lock
CONFLICT (content): Merge conflict in src/Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

This commit cleans up allocator injection logic found in the compiler around selecting the global allocator. It turns out that now that jemalloc is gone the compiler never actually injects anything! This means that basically everything around loading crates here and there can be easily pruned. This also removes the `exe_allocation_crate` option from custom target specs as it's no longer used by the compiler anywhere.

This commit deletes the `alloc_system` crate from the standard distribution. This unstable crate is no longer needed in the modern stable global allocator world, but rather its functionality is folded directly into the standard library. The standard library was already the only stable location to access this crate, and as a result this should not affect any stable code.

alexcrichton · 2018-11-11T17:23:25Z

@bors: r=dtolnay,SimonSapin

bors · 2018-11-11T17:23:25Z

📌 Commit cc75903 has been approved by dtolnay,SimonSapin

bors · 2018-11-11T19:52:02Z

⌛ Testing commit cc75903 with merge ca79ecd...

…imonSapin Remove the `alloc_system` crate In what's hopefully one of the final nails in the coffin of the "old allocator story of yore" this PR deletes the `alloc_system` crate and all traces of it from the compiler. The compiler no longer needs to inject allocator crates anywhere and the `alloc_system` crate has no real reason to exist outside the standard library. The unstable `alloc_system` crate is folded directly into the standard library where its stable interface, the `System` type, remains the same. All unstable traces of `alloc_system` are removed, however.

bors · 2018-11-11T22:38:48Z

☀️ Test successful - status-appveyor, status-travis
Approved by: dtolnay,SimonSapin
Pushing ca79ecd to master...

bjorn3 · 2018-11-12T18:17:41Z

src/libstd/alloc.rs

+/// This is based on `malloc` on Unix platforms and `HeapAlloc` on Windows,
+/// plus related functions.
+///
+/// This type implements the `GlobalAlloc` trait and Rust programs by deafult


jplatte · 2019-05-06T11:50:50Z

What's the story for using the system allocator in a no_std staticlib / binary (one that doesn't want to depend on std because of the networking / threading dependencies std brings with it, but that does depend on libc)? Copying even just one impl GlobalAlloc for System from std (e.g. the unix one) seems very undesireable.

SimonSapin · 2019-05-06T12:09:13Z

So far there is no story.

The point of no_std is to not depend on environment-provided facilities like std::alloc::System. Maybe some day there will be a mechanism for more fine-grained opt-in/opt-out, but today it’s all or nothing.

We could probably extract the existing impls into crates on crates.io (global_alloc_libc, global_alloc_windows, etc) and have std depend on those like it already does for wasm/dlmalloc. But a merged PR is not the place to have a discussion about further work. Consider filing a new issue or starting a thread on https://internals.rust-lang.org.

jplatte · 2019-05-06T12:15:07Z

I cross-posted to users.rust-lang.org. Should I move that thread to internals?

rust-highfive assigned dtolnay Nov 3, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 3, 2018

alexcrichton commented Nov 3, 2018

View reviewed changes

kevinmehall reviewed Nov 3, 2018

View reviewed changes

rust-highfive assigned SimonSapin and unassigned dtolnay Nov 3, 2018

mattico reviewed Nov 4, 2018

View reviewed changes

alexcrichton force-pushed the cleanup-alloc-system branch from 80e88cf to 7fa5adf Compare November 5, 2018 16:04

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 5, 2018

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 6, 2018

alexcrichton force-pushed the cleanup-alloc-system branch from 7fa5adf to 1116d6e Compare November 6, 2018 15:11

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 6, 2018

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 11, 2018

alexcrichton added 2 commits November 11, 2018 09:22

alexcrichton force-pushed the cleanup-alloc-system branch from 1116d6e to cc75903 Compare November 11, 2018 17:23

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 11, 2018

bors merged commit cc75903 into rust-lang:master Nov 11, 2018

bors mentioned this pull request Nov 11, 2018

Make NodeId and HirLocalId newtype_index #55750

Merged

alexcrichton deleted the cleanup-alloc-system branch November 11, 2018 23:36

bjorn3 reviewed Nov 12, 2018

View reviewed changes

dtolnay self-assigned this Mar 24, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove the `alloc_system` crate #55660

Remove the `alloc_system` crate #55660

alexcrichton commented Nov 3, 2018

rust-highfive commented Nov 3, 2018

alexcrichton Nov 3, 2018

kevinmehall Nov 3, 2018

dtolnay commented Nov 3, 2018

SimonSapin commented Nov 4, 2018

mattico Nov 4, 2018

alexcrichton commented Nov 5, 2018

bors commented Nov 5, 2018

bors commented Nov 6, 2018

alexcrichton commented Nov 6, 2018

bors commented Nov 6, 2018

sfackler commented Nov 6, 2018

frewsxcv commented Nov 10, 2018

bors commented Nov 11, 2018

alexcrichton commented Nov 11, 2018

bors commented Nov 11, 2018

bors commented Nov 11, 2018

bors commented Nov 11, 2018

bjorn3 Nov 12, 2018

jplatte commented May 6, 2019 •

edited

Loading

SimonSapin commented May 6, 2019

jplatte commented May 6, 2019

Remove the alloc_system crate #55660

Remove the alloc_system crate #55660

Conversation

alexcrichton commented Nov 3, 2018

rust-highfive commented Nov 3, 2018

alexcrichton Nov 3, 2018

Choose a reason for hiding this comment

kevinmehall Nov 3, 2018

Choose a reason for hiding this comment

dtolnay commented Nov 3, 2018

SimonSapin commented Nov 4, 2018

mattico Nov 4, 2018

Choose a reason for hiding this comment

alexcrichton commented Nov 5, 2018

bors commented Nov 5, 2018

bors commented Nov 6, 2018

alexcrichton commented Nov 6, 2018

bors commented Nov 6, 2018

sfackler commented Nov 6, 2018

frewsxcv commented Nov 10, 2018

bors commented Nov 11, 2018

alexcrichton commented Nov 11, 2018

bors commented Nov 11, 2018

bors commented Nov 11, 2018

bors commented Nov 11, 2018

bjorn3 Nov 12, 2018

Choose a reason for hiding this comment

jplatte commented May 6, 2019 • edited Loading

SimonSapin commented May 6, 2019

jplatte commented May 6, 2019

Remove the `alloc_system` crate #55660

Remove the `alloc_system` crate #55660

jplatte commented May 6, 2019 •

edited

Loading