Add atomic module to alloc::sync

[taiki-e]

Of the modules of the alloc crate, modules with the same names with the core crate except prelude and sync are re-exporting items of the same name module of the core crate.

I think should also be done for alloc::sync.

cc rust-lang/rfcs#2480

[rust-highfive]

r? @aidanhs

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

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:13227c60:start=1549330018218081474,finish=1549330019117057015,duration=898975541
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0

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 @TimNN. (Feature Requests)

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:03626e7a:start=1549440373640777592,finish=1549440448082992966,duration=74442215374
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:10:55] [01:10:55] running 119 tests
[01:11:21] .iiiii...i.....i..i...i..i.i..i.ii...i.....i..i....i..........iiii..........i...ii...i.......ii.i.i. 100/119
[01:11:26] i......iii.i.....ii
[01:11:26] [01:11:26] finished in 30.393
[01:11:26] travis_fold:end:test_debuginfo
---
[01:36:42] travis_fold:end:stage0-linkchecker
[01:36:42] travis_time:end:stage0-linkchecker:start=1549446257710709606,finish=1549446259623088878,duration=1912379272
[01:36:43] alloc/sync/atomic/index.html:13: broken link - alloc/marker/trait.Sync.html
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:098bced4
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Wed Feb 6 09:44:27 UTC 2019
---
travis_time:end:0ff3da40:start=1549446269199554678,finish=1549446269256814024,duration=57259346
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:03cc1174
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:04b140d7
$ dmesg | grep -i kill

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 @TimNN. (Feature Requests)

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:026e003a:start=1549669934240811867,finish=1549670008746836906,duration=74506025039
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:10:27] [01:10:27] running 119 tests
[01:10:52] .iiiii...i.....i..i...i..i.i..i.ii...i.....i..i....i..........iiii..........i...ii...i.......ii.i.i. 100/119
[01:10:56] i......iii.i.....ii
[01:10:56] [01:10:56] finished in 29.312
[01:10:56] travis_fold:end:test_debuginfo
---
[01:35:57] travis_fold:end:stage0-linkchecker
[01:35:57] travis_time:end:stage0-linkchecker:start=1549675772549704369,finish=1549675774626307748,duration=2076603379
[01:35:58] alloc/sync/atomic/index.html:13: broken link - alloc/marker/trait.Sync.html
[01:36:05] thread 'main' panicked at 'found some broken links', src/tools/linkchecker/main.rs:41:9
[01:36:05] [01:36:05] [01:36:05] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/linkchecker" "/checkout/obj/build/x86_64-unknown-linux-gnu/doc"
[01:36:05] expected success, got: exit code: 101
[01:36:05] expected success, got: exit code: 101
[01:36:05] [01:36:05] [01:36:05] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:36:05] Build completed unsuccessfully in 0:37:12
[01:36:05] make: *** [check] Error 1
[01:36:05] Makefile:48: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:060fb820
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sat Feb 9 01:29:43 UTC 2019

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 @TimNN. (Feature Requests)

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:145d5110:start=1550435248266383567,finish=1550435249044308162,duration=777924595
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-6.0
---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:11:36] [01:11:36] running 119 tests
[01:12:01] .iiiii...i.....i..i...i..i.i..i.ii...i.....i..i....i..........iiii..........i...ii...i.......ii.i.i. 100/119
[01:12:05] i......iii.i.....ii
[01:12:05] [01:12:05] finished in 28.585
[01:12:05] travis_fold:end:test_debuginfo
---
[01:37:51] travis_fold:end:stage0-linkchecker
[01:37:51] travis_time:end:stage0-linkchecker:start=1550441129215788670,finish=1550441131230971896,duration=2015183226
[01:37:51] alloc/sync/atomic/index.html:5: broken link - alloc/std/sync/atomic/index.html
[01:37:58] thread 'main' panicked at 'found some broken links', src/tools/linkchecker/main.rs:41:9
[01:37:58] [01:37:58] [01:37:58] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/linkchecker" "/checkout/obj/build/x86_64-unknown-linux-gnu/doc"
[01:37:58] expected success, got: exit code: 101
[01:37:58] expected success, got: exit code: 101
[01:37:58] [01:37:58] [01:37:58] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:37:58] Build completed unsuccessfully in 0:37:51
[01:37:58] Makefile:48: recipe for target 'check' failed
[01:37:58] make: *** [check] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:07a27fe2
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sun Feb 17 22:05:39 UTC 2019

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 @TimNN. (Feature Requests)

[taiki-e]

r? @SimonSapin

[SimonSapin]

Good catch! RFC 2480 states a similar goal: alloc is a subset of std (modulo prelude)

Except for the alloc::prelude module, since PR #51569 the module structure is a subset of that of std: every path that starts with alloc:: is still valid and point to the same item after replacing that prefix with std:: (assuming both crates are available).

I agree that it should also be a superset of core.

Regarding this PR’s implementation, I think it can be a single pub use reexport of the module rather than a new module with a glob reexport.

As to stability, I think it should be the same as core::sync::atomic. (Stable.)

[SimonSapin]

I agree that it should also be a superset of core.

Hmm on a closer look I’m not sure. There are many other modules that are present in libcore but not liballoc. core::option, core::iter, …

[taiki-e]

I added a description.

[taiki-e]

Specifically, it is this error: #58175 (comment)

[01:36:43] alloc/sync/atomic/index.html:13: broken link - alloc/marker/trait.Sync.html

[taiki-e]

Regarding this PR’s implementation, I think it can be a single pub use reexport of the module rather than a new module with a glob reexport.

See #58175 (comment).

As to stability, I think it should be the same as core::sync::atomic. (Stable.)

Thanks, I changed it.

[SimonSapin]

@rust-lang/libs Any thoughts on whether liballoc should be a superset of libcore?

[Amanieu]

@SimonSapin I personally don't mind either way.

[alexcrichton]

Agreed this should be fine to land

[SimonSapin]

Oh I see, there’s a subtlety that I missed in the PR description: for modules that exist in both crates, this makes alloc::$module::* a superset of core::$module::*.

I think that conditional is not useful. If we care about having what’s in libcore, I’d rather we do that at the crate level and reexport everything. (alloc::* is a superset of core::*).

[taiki-e]

Any thoughts on whether liballoc should be a superset of libcore?

There is no sentence clearly specifying this in rust-lang/rfcs#2480, but the following sentence looks like to contain "alloc should be a superset of core".

no_std with an allocator:

An intermediate subset of the standard library smaller than “all of std” but larger than “only core” can serve such environments.

[taiki-e]

@SimonSapin

Oh I see, there’s a subtlety that I missed in the PR description: for modules that exist in both crates, this makes alloc::$module::* a superset of core::$module::*.

I think that conditional is not useful. If we care about having what’s in libcore, I’d rather we do that at the crate level and reexport everything. (alloc::* is a superset of core::*).

The current alloc is incomplete "alloc::$module::* a superset of core::$module::*".

[taiki-e]

FYI: Comparison of imports

std

use std::borrow::{Borrow,Cow};use std::iter;use std::sync::{atomic,Arc};

current no_std + alloc:

use alloc::borrow::{Borrow,Cow};use alloc::sync::Arc;use core::iter;use core::sync::atomic;

after this PR:

use alloc::borrow::{Borrow,Cow};use alloc::sync::{atomic,Arc};use core::iter;

if alloc is superset of core

use alloc::borrow::{Borrow,Cow};use alloc::iter;use alloc::sync::{atomic,Arc};

[Amanieu]

On second thought, I think that use alloc::iter; looks very strage: why are we importing something that is completely unrelated to allocation from a crate named alloc.

If we really want to keep pushing in that direction then we should consider renaming alloc to something like core_alloc (libcore + global allocator).

[SimonSapin]

@taiki-e That RFC is not accepted yet and can still evolve, so don’t read too much is what exactly it says or not. In fact I think this very conversation will affect the RFC. As to the “intermediate” subset, it doesn’t have to be imported all from one crate. Whenever liballoc is available, libcore is too.

@Amanieu If alloc::iter looks strange, does alloc::sync::atomic look strange in the same way?

Whether to rename the alloc crate is an unresolved question of RFC 2480.

[Amanieu]

@SimonSapin Yes, I would say that alloc::sync::atomic looks strange as well.

IMO the only 2 approaches that make sense are:

1. Keep the alloc crate as it is today, where it only contains things that depend on the global allocator.
2. Rename alloc to core_alloc and make it a superset of core and a subset of std.

I am personally happy with either approach.

[Dylan-DPC-zz]

ping from triage @taiki-e@SimonSapin what's the update on this?

[SimonSapin]

I agree with @Amanieu about the two approaches. I’ve added an unresolved question to rust-lang/rfcs#2480 about picking one. (I think I prefer the status quo.) I’ll close this PR since it does neither of those approaches, but thanks for the patch @taiki-e!