New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move std::os::raw::c_void into libcore and re-export in libstd #53910

Merged
merged 1 commit into from Sep 17, 2018

Conversation

Projects
None yet
8 participants
@IsaacWoods
Contributor

IsaacWoods commented Sep 2, 2018

Implements the first part of RFC 2521.

cc #53856

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 2, 2018

Collaborator

r? @shepmaster

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

Collaborator

rust-highfive commented Sep 2, 2018

r? @shepmaster

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

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 2, 2018

Collaborator

The job x86_64-gnu-llvm-5.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.
[00:05:05]    Compiling rustc_asan v0.0.0 (file:///checkout/src/librustc_asan)
[00:05:06]    Compiling rustc_tsan v0.0.0 (file:///checkout/src/librustc_tsan)
[00:05:07]    Compiling rustc_msan v0.0.0 (file:///checkout/src/librustc_msan)
[00:05:08]    Compiling rustc_lsan v0.0.0 (file:///checkout/src/librustc_lsan)
[00:05:12] warning: type `c_void` should have a camel case name such as `CVoid`
[00:05:12]   --> libcore/ffi.rs:26:1
[00:05:12]    |
[00:05:12] 26 | / pub enum c_void {
[00:05:12] 27 | |     #[unstable(feature = "c_void_variant", reason = "should not have to exist",
[00:05:12] 28 | |                issue = "0")]
[00:05:12] 29 | |     #[doc(hidden)] __variant1,
[00:05:12] ...  |
[00:05:12] 32 | |     #[doc(hidden)] __variant2,
[00:05:12]    | |_^
[00:05:12]    |
[00:05:12]    = note: #[warn(non_camel_case_types)] on by default
[00:05:12] 
[00:05:12] 
[00:05:12] warning: variant `__variant1` should have a camel case name such as `Variant1`
[00:05:12]   --> libcore/ffi.rs:29:20
[00:05:12]    |
[00:05:12] 29 |     #[doc(hidden)] __variant1,
[00:05:12] 
[00:05:12] 
[00:05:12] warning: variant `__variant2` should have a camel case name such as `Variant2`
[00:05:12]   --> libcore/ffi.rs:32:20
[00:05:12]    |
[00:05:12] 32 |     #[doc(hidden)] __variant2,
[00:05:12] 
[00:05:19]    Compiling libc v0.0.0 (file:///checkout/src/rustc/libc_shim)
[00:05:19]    Compiling alloc v0.0.0 (file:///checkout/src/liballoc)
[00:05:20]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)

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)

Collaborator

rust-highfive commented Sep 2, 2018

The job x86_64-gnu-llvm-5.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.
[00:05:05]    Compiling rustc_asan v0.0.0 (file:///checkout/src/librustc_asan)
[00:05:06]    Compiling rustc_tsan v0.0.0 (file:///checkout/src/librustc_tsan)
[00:05:07]    Compiling rustc_msan v0.0.0 (file:///checkout/src/librustc_msan)
[00:05:08]    Compiling rustc_lsan v0.0.0 (file:///checkout/src/librustc_lsan)
[00:05:12] warning: type `c_void` should have a camel case name such as `CVoid`
[00:05:12]   --> libcore/ffi.rs:26:1
[00:05:12]    |
[00:05:12] 26 | / pub enum c_void {
[00:05:12] 27 | |     #[unstable(feature = "c_void_variant", reason = "should not have to exist",
[00:05:12] 28 | |                issue = "0")]
[00:05:12] 29 | |     #[doc(hidden)] __variant1,
[00:05:12] ...  |
[00:05:12] 32 | |     #[doc(hidden)] __variant2,
[00:05:12]    | |_^
[00:05:12]    |
[00:05:12]    = note: #[warn(non_camel_case_types)] on by default
[00:05:12] 
[00:05:12] 
[00:05:12] warning: variant `__variant1` should have a camel case name such as `Variant1`
[00:05:12]   --> libcore/ffi.rs:29:20
[00:05:12]    |
[00:05:12] 29 |     #[doc(hidden)] __variant1,
[00:05:12] 
[00:05:12] 
[00:05:12] warning: variant `__variant2` should have a camel case name such as `Variant2`
[00:05:12]   --> libcore/ffi.rs:32:20
[00:05:12]    |
[00:05:12] 32 |     #[doc(hidden)] __variant2,
[00:05:12] 
[00:05:19]    Compiling libc v0.0.0 (file:///checkout/src/rustc/libc_shim)
[00:05:19]    Compiling alloc v0.0.0 (file:///checkout/src/liballoc)
[00:05:20]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)

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)

@SimonSapin SimonSapin added the T-libs label Sep 3, 2018

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 3, 2018

Contributor

Looks good, thanks! As Travis-CI suggests, this needs #![warn(non_camel_case_types)] in src/libcore/ffi.rs.

@rust-lang/libs, how do you feel about core::ffi and core::ffi::c_void being insta-stable? I think it’s fine since the type is already stable under std::os::raw::c_void, but let’s formally get team sign off:

@rfcbot merge

Contributor

SimonSapin commented Sep 3, 2018

Looks good, thanks! As Travis-CI suggests, this needs #![warn(non_camel_case_types)] in src/libcore/ffi.rs.

@rust-lang/libs, how do you feel about core::ffi and core::ffi::c_void being insta-stable? I think it’s fine since the type is already stable under std::os::raw::c_void, but let’s formally get team sign off:

@rfcbot merge

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 3, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot commented Sep 3, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 3, 2018

Collaborator

The job x86_64-gnu-llvm-5.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.
[00:04:51]    Compiling rustc_lsan v0.0.0 (file:///checkout/src/librustc_lsan)
[00:04:52]    Compiling rustc_asan v0.0.0 (file:///checkout/src/librustc_asan)
[00:04:53]    Compiling rustc_msan v0.0.0 (file:///checkout/src/librustc_msan)
[00:04:54]    Compiling rustc_tsan v0.0.0 (file:///checkout/src/librustc_tsan)
[00:04:59] warning: type `c_void` should have a camel case name such as `CVoid`
[00:04:59]   --> libcore/ffi.rs:28:1
[00:04:59]    |
[00:04:59] 28 | / pub enum c_void {
[00:04:59] 29 | |     #[unstable(feature = "c_void_variant", reason = "should not have to exist",
[00:04:59] 30 | |                issue = "0")]
[00:04:59] 31 | |     #[doc(hidden)] __variant1,
[00:04:59] ...  |
[00:04:59] 34 | |     #[doc(hidden)] __variant2,
[00:04:59]    | |_^
[00:04:59]    |
[00:04:59] note: lint level defined here
[00:04:59]   --> libcore/ffi.rs:3:9
[00:04:59]   --> libcore/ffi.rs:3:9
[00:04:59]    |
[00:04:59] 3  | #![warn(non_camel_case_types)]
[00:04:59] 
[00:04:59] 
[00:04:59] warning: variant `__variant1` should have a camel case name such as `Variant1`
[00:04:59]   --> libcore/ffi.rs:31:20
[00:04:59]    |
[00:04:59] 31 |     #[doc(hidden)] __variant1,
[00:04:59] 
[00:04:59] 
[00:04:59] warning: variant `__variant2` should have a camel case name such as `Variant2`
[00:04:59]   --> libcore/ffi.rs:34:20
[00:04:59]    |
[00:04:59] 34 |     #[doc(hidden)] __variant2,
[00:04:59] 
[00:05:07]    Compiling libc v0.0.0 (file:///checkout/src/rustc/libc_shim)
[00:05:07]    Compiling alloc v0.0.0 (file:///checkout/src/liballoc)
[00:05:08]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)
---
[00:21:14]    Compiling rustc_tsan v0.0.0 (file:///checkout/src/librustc_tsan)
[00:21:15]    Compiling rustc_lsan v0.0.0 (file:///checkout/src/librustc_lsan)
[00:21:15]    Compiling rustc_asan v0.0.0 (file:///checkout/src/librustc_asan)
[00:21:16]    Compiling rustc_msan v0.0.0 (file:///checkout/src/librustc_msan)
[00:21:41] error: type `c_void` should have a camel case name such as `CVoid`
[00:21:41]   --> libcore/ffi.rs:28:1
[00:21:41]    |
[00:21:41] 28 | / pub enum c_void {
[00:21:41] 29 | |     #[unstable(feature = "c_void_variant", reason = "should not have to exist",
[00:21:41] 30 | |                issue = "0")]
[00:21:41] 31 | |     #[doc(hidden)] __variant1,
[00:21:41] ...  |
[00:21:41] 34 | |     #[doc(hidden)] __variant2,
[00:21:41]    | |_^
[00:21:41]    |
[00:21:41]    = note: `-D non-camel-case-types` implied by `-D warnings`
[00:21:41] 
[00:21:41] 
[00:21:41] error: variant `__variant1` should have a camel case name such as `Variant1`
[00:21:41]   --> libcore/ffi.rs:31:20
[00:21:41]    |
[00:21:41] 31 |     #[doc(hidden)] __variant1,
[00:21:41] 
[00:21:41] 
[00:21:41] error: variant `__variant2` should have a camel case name such as `Variant2`
[00:21:41]   --> libcore/ffi.rs:34:20
[00:21:41]    |
[00:21:41] 34 |     #[doc(hidden)] __variant2,
[00:21:41] 
[00:21:41] error: aborting due to 3 previous errors
[00:21:41] 
[00:21:41] error: Could not compile `core`.
---
[00:21:41] travis_time:end:stage1-std:start=1535992315236917460,finish=1535992353549151273,duration=38312233813

[00:21:41] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:21:41] expected success, got: exit code: 101
[00:21:41] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1155:9
[00:21:41] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap build
[00:21:41] Build completed unsuccessfully in 0:17:03
[00:21:41] Makefile:28: recipe for target 'all' failed
[00:21:41] Makefile:28: recipe for target 'all' failed
[00:21:41] make: *** [all] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1591c8c6
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:2ba46855:start=1535992354384614073,finish=1535992354394893789,duration=10279716
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0ffb88c0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:15554e17
travis_time:start:15554e17
$ 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:0137bc53
$ 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)

Collaborator

rust-highfive commented Sep 3, 2018

The job x86_64-gnu-llvm-5.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.
[00:04:51]    Compiling rustc_lsan v0.0.0 (file:///checkout/src/librustc_lsan)
[00:04:52]    Compiling rustc_asan v0.0.0 (file:///checkout/src/librustc_asan)
[00:04:53]    Compiling rustc_msan v0.0.0 (file:///checkout/src/librustc_msan)
[00:04:54]    Compiling rustc_tsan v0.0.0 (file:///checkout/src/librustc_tsan)
[00:04:59] warning: type `c_void` should have a camel case name such as `CVoid`
[00:04:59]   --> libcore/ffi.rs:28:1
[00:04:59]    |
[00:04:59] 28 | / pub enum c_void {
[00:04:59] 29 | |     #[unstable(feature = "c_void_variant", reason = "should not have to exist",
[00:04:59] 30 | |                issue = "0")]
[00:04:59] 31 | |     #[doc(hidden)] __variant1,
[00:04:59] ...  |
[00:04:59] 34 | |     #[doc(hidden)] __variant2,
[00:04:59]    | |_^
[00:04:59]    |
[00:04:59] note: lint level defined here
[00:04:59]   --> libcore/ffi.rs:3:9
[00:04:59]   --> libcore/ffi.rs:3:9
[00:04:59]    |
[00:04:59] 3  | #![warn(non_camel_case_types)]
[00:04:59] 
[00:04:59] 
[00:04:59] warning: variant `__variant1` should have a camel case name such as `Variant1`
[00:04:59]   --> libcore/ffi.rs:31:20
[00:04:59]    |
[00:04:59] 31 |     #[doc(hidden)] __variant1,
[00:04:59] 
[00:04:59] 
[00:04:59] warning: variant `__variant2` should have a camel case name such as `Variant2`
[00:04:59]   --> libcore/ffi.rs:34:20
[00:04:59]    |
[00:04:59] 34 |     #[doc(hidden)] __variant2,
[00:04:59] 
[00:05:07]    Compiling libc v0.0.0 (file:///checkout/src/rustc/libc_shim)
[00:05:07]    Compiling alloc v0.0.0 (file:///checkout/src/liballoc)
[00:05:08]    Compiling alloc_system v0.0.0 (file:///checkout/src/liballoc_system)
---
[00:21:14]    Compiling rustc_tsan v0.0.0 (file:///checkout/src/librustc_tsan)
[00:21:15]    Compiling rustc_lsan v0.0.0 (file:///checkout/src/librustc_lsan)
[00:21:15]    Compiling rustc_asan v0.0.0 (file:///checkout/src/librustc_asan)
[00:21:16]    Compiling rustc_msan v0.0.0 (file:///checkout/src/librustc_msan)
[00:21:41] error: type `c_void` should have a camel case name such as `CVoid`
[00:21:41]   --> libcore/ffi.rs:28:1
[00:21:41]    |
[00:21:41] 28 | / pub enum c_void {
[00:21:41] 29 | |     #[unstable(feature = "c_void_variant", reason = "should not have to exist",
[00:21:41] 30 | |                issue = "0")]
[00:21:41] 31 | |     #[doc(hidden)] __variant1,
[00:21:41] ...  |
[00:21:41] 34 | |     #[doc(hidden)] __variant2,
[00:21:41]    | |_^
[00:21:41]    |
[00:21:41]    = note: `-D non-camel-case-types` implied by `-D warnings`
[00:21:41] 
[00:21:41] 
[00:21:41] error: variant `__variant1` should have a camel case name such as `Variant1`
[00:21:41]   --> libcore/ffi.rs:31:20
[00:21:41]    |
[00:21:41] 31 |     #[doc(hidden)] __variant1,
[00:21:41] 
[00:21:41] 
[00:21:41] error: variant `__variant2` should have a camel case name such as `Variant2`
[00:21:41]   --> libcore/ffi.rs:34:20
[00:21:41]    |
[00:21:41] 34 |     #[doc(hidden)] __variant2,
[00:21:41] 
[00:21:41] error: aborting due to 3 previous errors
[00:21:41] 
[00:21:41] error: Could not compile `core`.
---
[00:21:41] travis_time:end:stage1-std:start=1535992315236917460,finish=1535992353549151273,duration=38312233813

[00:21:41] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "--message-format" "json"
[00:21:41] expected success, got: exit code: 101
[00:21:41] thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1155:9
[00:21:41] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap build
[00:21:41] Build completed unsuccessfully in 0:17:03
[00:21:41] Makefile:28: recipe for target 'all' failed
[00:21:41] Makefile:28: recipe for target 'all' failed
[00:21:41] make: *** [all] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1591c8c6
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:2ba46855:start=1535992354384614073,finish=1535992354394893789,duration=10279716
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0ffb88c0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:15554e17
travis_time:start:15554e17
$ 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:0137bc53
$ 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

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 3, 2018

Collaborator

The job x86_64-gnu-llvm-5.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.
[00:48:44] ....................................................................................................
[00:48:48] ....................................................................................................
[00:48:50] ......................i.............................................................................
[00:48:53] ....................................................................................................
[00:48:56] .......................................................................iiiiiiiii....................
[00:49:01] ....................................................................................................
[00:49:05] ....................................................................................................
[00:49:08] ....................................................i...............................................
[00:49:11] ....................................................................................................
---
[01:16:35] travis_fold:end:stage0-linkchecker

[01:16:35] travis_time:end:stage0-linkchecker:start=1536002897316875936,finish=1536002899729486704,duration=2412610768

[01:16:41] std/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
[01:16:41] std/ffi/enum.c_void.html:8: broken link - primitive.never.html
[01:16:41] std/ffi/index.html:190: broken link - primitive.pointer.html
[01:16:45] core/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
[01:16:45] core/ffi/enum.c_void.html:8: broken link - primitive.never.html
[01:16:45] core/ffi/index.html:8: broken link - primitive.pointer.html
[01:16:49] thread 'main' panicked at 'found some broken links', tools/linkchecker/main.rs:49:9
[01:16:49] 
[01:16:49] 
[01:16:49] 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:16:49] expected success, got: exit code: 101
[01:16:49] expected success, got: exit code: 101
[01:16:49] 
[01:16:49] 
[01:16:49] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:16:49] Build completed unsuccessfully in 0:32:08
[01:16:49] make: *** [check] Error 1
[01:16:49] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:02e76944
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

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)

Collaborator

rust-highfive commented Sep 3, 2018

The job x86_64-gnu-llvm-5.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.
[00:48:44] ....................................................................................................
[00:48:48] ....................................................................................................
[00:48:50] ......................i.............................................................................
[00:48:53] ....................................................................................................
[00:48:56] .......................................................................iiiiiiiii....................
[00:49:01] ....................................................................................................
[00:49:05] ....................................................................................................
[00:49:08] ....................................................i...............................................
[00:49:11] ....................................................................................................
---
[01:16:35] travis_fold:end:stage0-linkchecker

[01:16:35] travis_time:end:stage0-linkchecker:start=1536002897316875936,finish=1536002899729486704,duration=2412610768

[01:16:41] std/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
[01:16:41] std/ffi/enum.c_void.html:8: broken link - primitive.never.html
[01:16:41] std/ffi/index.html:190: broken link - primitive.pointer.html
[01:16:45] core/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
[01:16:45] core/ffi/enum.c_void.html:8: broken link - primitive.never.html
[01:16:45] core/ffi/index.html:8: broken link - primitive.pointer.html
[01:16:49] thread 'main' panicked at 'found some broken links', tools/linkchecker/main.rs:49:9
[01:16:49] 
[01:16:49] 
[01:16:49] 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:16:49] expected success, got: exit code: 101
[01:16:49] expected success, got: exit code: 101
[01:16:49] 
[01:16:49] 
[01:16:49] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:16:49] Build completed unsuccessfully in 0:32:08
[01:16:49] make: *** [check] Error 1
[01:16:49] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:02e76944
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

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

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 4, 2018

Collaborator

The job x86_64-gnu-llvm-5.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.
[00:48:49] ....................................................................................................
[00:48:52] ....................................................................................................
[00:48:55] ...........................i........................................................................
[00:48:58] ....................................................................................................
[00:49:01] ............................................................................iiiiiiiii...............
[00:49:06] ....................................................................................................
[00:49:10] ....................................................................................................
[00:49:13] .........................................................i..........................................
[00:49:16] ....................................................................................................
---
[01:17:13] travis_fold:end:stage0-linkchecker

[01:17:13] travis_time:end:stage0-linkchecker:start=1536067314162849865,finish=1536067316525866419,duration=2363016554

[01:17:18] std/os/raw/enum.c_void.html:4: broken link - std/std/primitive.pointer.html
[01:17:18] std/os/raw/enum.c_void.html:8: broken link - std/std/primitive.never.html
[01:17:18] std/os/raw/index.html:13: broken link - std/std/primitive.pointer.html
[01:17:29] thread 'main' panicked at 'found some broken links', tools/linkchecker/main.rs:49:9
[01:17:29] 
[01:17:29] 
[01:17:29] 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:17:29] expected success, got: exit code: 101
[01:17:29] expected success, got: exit code: 101
[01:17:29] 
[01:17:29] 
[01:17:29] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:17:29] Build completed unsuccessfully in 0:32:46
[01:17:29] make: *** [check] Error 1
[01:17:29] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1b68c3cb
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

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)

Collaborator

rust-highfive commented Sep 4, 2018

The job x86_64-gnu-llvm-5.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.
[00:48:49] ....................................................................................................
[00:48:52] ....................................................................................................
[00:48:55] ...........................i........................................................................
[00:48:58] ....................................................................................................
[00:49:01] ............................................................................iiiiiiiii...............
[00:49:06] ....................................................................................................
[00:49:10] ....................................................................................................
[00:49:13] .........................................................i..........................................
[00:49:16] ....................................................................................................
---
[01:17:13] travis_fold:end:stage0-linkchecker

[01:17:13] travis_time:end:stage0-linkchecker:start=1536067314162849865,finish=1536067316525866419,duration=2363016554

[01:17:18] std/os/raw/enum.c_void.html:4: broken link - std/std/primitive.pointer.html
[01:17:18] std/os/raw/enum.c_void.html:8: broken link - std/std/primitive.never.html
[01:17:18] std/os/raw/index.html:13: broken link - std/std/primitive.pointer.html
[01:17:29] thread 'main' panicked at 'found some broken links', tools/linkchecker/main.rs:49:9
[01:17:29] 
[01:17:29] 
[01:17:29] 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:17:29] expected success, got: exit code: 101
[01:17:29] expected success, got: exit code: 101
[01:17:29] 
[01:17:29] 
[01:17:29] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:17:29] Build completed unsuccessfully in 0:32:46
[01:17:29] make: *** [check] Error 1
[01:17:29] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1b68c3cb
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

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)

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 4, 2018

Contributor

Rather than changing the links, maybe it’d be better to add #[doc(inline)] on the pub use item that replaced the previous enum?

Contributor

SimonSapin commented Sep 4, 2018

Rather than changing the links, maybe it’d be better to add #[doc(inline)] on the pub use item that replaced the previous enum?

@IsaacWoods

This comment has been minimized.

Show comment
Hide comment
@IsaacWoods

IsaacWoods Sep 5, 2018

Contributor

@SimonSapin Tried this and tested locally (./x.py test src/tools/linkchecker) and that gives:

std/ffi/index.html:190: broken link - primitive.pointer.html
std/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
std/ffi/enum.c_void.html:8: broken link - primitive.never.html
core/ffi/index.html:8: broken link - primitive.pointer.html
core/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
core/ffi/enum.c_void.html:8: broken link - primitive.never.html

I don't think we could use the same link from all three places (core::ffi, std::ffi and std::os::raw) whatever it was. Is there a way to link absolutely to those pages?

Contributor

IsaacWoods commented Sep 5, 2018

@SimonSapin Tried this and tested locally (./x.py test src/tools/linkchecker) and that gives:

std/ffi/index.html:190: broken link - primitive.pointer.html
std/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
std/ffi/enum.c_void.html:8: broken link - primitive.never.html
core/ffi/index.html:8: broken link - primitive.pointer.html
core/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
core/ffi/enum.c_void.html:8: broken link - primitive.never.html

I don't think we could use the same link from all three places (core::ffi, std::ffi and std::os::raw) whatever it was. Is there a way to link absolutely to those pages?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 5, 2018

Contributor

Sorry, in my previous comment I was only thinking of links to c_void and I didn’t realize that the broken links were in fact the ones in c_void’s own documentation.

Indeed, std::os::raw being at a different depth than std::ffi and core::ffi makes relative links tricky. However absolute links are not acceptable as we don’t know where docs will be based. For example on my machine running rustup doc --std opens file:///home/simon/tmp/rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/std/index.html.

So we probably need to not use #[doc(inline)] here. But it looks like #53910 (comment) failed without as it still has broken links in std::os::raw, which I did not expect. What does the docs for std::os::raw look like? Is the doc-comment of c_void inlined "through" the pub use re-export?

Contributor

SimonSapin commented Sep 5, 2018

Sorry, in my previous comment I was only thinking of links to c_void and I didn’t realize that the broken links were in fact the ones in c_void’s own documentation.

Indeed, std::os::raw being at a different depth than std::ffi and core::ffi makes relative links tricky. However absolute links are not acceptable as we don’t know where docs will be based. For example on my machine running rustup doc --std opens file:///home/simon/tmp/rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/std/index.html.

So we probably need to not use #[doc(inline)] here. But it looks like #53910 (comment) failed without as it still has broken links in std::os::raw, which I did not expect. What does the docs for std::os::raw look like? Is the doc-comment of c_void inlined "through" the pub use re-export?

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 5, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot commented Sep 5, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@IsaacWoods

This comment has been minimized.

Show comment
Hide comment
@IsaacWoods

IsaacWoods Sep 5, 2018

Contributor

Fair enough, I was hoping it would be to the root of the documentation, so e.g. /std/primitive.never would work.

With no doc attribute, it shows c_void under Enums, so yeah I'm guessing it defaults to doc(inline). With #[doc(no_inline)], it shows under Re-exports and links to the page for std::ffi::c_void. I haven't checked yet, but I'm guessing if we put #[doc(no_inline)] on both pub uses and fixed the links to be correct from core::ffi::c_void, the linkchecker would be happy, but it would change libstd's docs. Is that an acceptable solution, if it works?

Contributor

IsaacWoods commented Sep 5, 2018

Fair enough, I was hoping it would be to the root of the documentation, so e.g. /std/primitive.never would work.

With no doc attribute, it shows c_void under Enums, so yeah I'm guessing it defaults to doc(inline). With #[doc(no_inline)], it shows under Re-exports and links to the page for std::ffi::c_void. I haven't checked yet, but I'm guessing if we put #[doc(no_inline)] on both pub uses and fixed the links to be correct from core::ffi::c_void, the linkchecker would be happy, but it would change libstd's docs. Is that an acceptable solution, if it works?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 5, 2018

Contributor

@rust-lang/docs, any thoughts on how we should handle this?

Contributor

SimonSapin commented Sep 5, 2018

@rust-lang/docs, any thoughts on how we should handle this?

@IsaacWoods

This comment has been minimized.

Show comment
Hide comment
@IsaacWoods

IsaacWoods Sep 5, 2018

Contributor

Update: adding #[doc(no_inline)] to both of the pub uses fixes the broken links in std::os::raw but not std::ffi, but I have no idea why. The generated docs look the same for both, showing pub use core::ffi::c_void; under a 'Re-exports' section, so it's not trying to inline the comment afaict.

The exact error from linkchecker is:

std/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
std/ffi/enum.c_void.html:8: broken link - primitive.never.html
Contributor

IsaacWoods commented Sep 5, 2018

Update: adding #[doc(no_inline)] to both of the pub uses fixes the broken links in std::os::raw but not std::ffi, but I have no idea why. The generated docs look the same for both, showing pub use core::ffi::c_void; under a 'Re-exports' section, so it's not trying to inline the comment afaict.

The exact error from linkchecker is:

std/ffi/enum.c_void.html:4: broken link - primitive.pointer.html
std/ffi/enum.c_void.html:8: broken link - primitive.never.html
@TimNN

This comment has been minimized.

Show comment
Hide comment
@TimNN

TimNN Sep 11, 2018

Contributor

Ping @rust-lang/docs & @rust-lang/rustdoc: It looks like there's some issues with pub uses broken links, could you take a look?

Contributor

TimNN commented Sep 11, 2018

Ping @rust-lang/docs & @rust-lang/rustdoc: It looks like there's some issues with pub uses broken links, could you take a look?

@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Sep 13, 2018

Member

Links in the std docs are incredibly fragile. Since this is something that exists in both core and std, you need to make sure that they're at the same directory level in both places.

In fact, looking at the current Travis error, you may be closer then you think...

[01:17:18] std/os/raw/enum.c_void.html:4: broken link - std/std/primitive.pointer.html
[01:17:18] std/os/raw/enum.c_void.html:8: broken link - std/std/primitive.never.html
[01:17:18] std/os/raw/index.html:13: broken link - std/std/primitive.pointer.html
[01:17:29] thread 'main' panicked at 'found some broken links', tools/linkchecker/main.rs:49:9
[01:17:29] note: Run with `RUST_BACKTRACE=1` for a backtrace.

It seems like it's only complaining about the re-export in std::os::raw, so i would suggest putting #[doc(no_inline)] just on that one.


What's happening here is that the link you gave it is relative to its file path. This enum appears in three places in this PR:

  • core::ffi
  • std::ffi
  • std::os::raw

Note that the module path for that last one is longer than the other two. This means that it has one more folder parent to pass through with .. to get back to the doc root. Sadly, this means that it's impossible to use the same link in all three places and still have it be valid.

(Strictly speaking, this is what "intra-doc links" were made to fix, but i'm not sure the primitive link will totally work out? For one, you'd need to add the reference into this array, but also, the primitive docs aren't even available in libcore! We'd have to fix rustdoc to make sure the link is handled correctly.)

Member

QuietMisdreavus commented Sep 13, 2018

Links in the std docs are incredibly fragile. Since this is something that exists in both core and std, you need to make sure that they're at the same directory level in both places.

In fact, looking at the current Travis error, you may be closer then you think...

[01:17:18] std/os/raw/enum.c_void.html:4: broken link - std/std/primitive.pointer.html
[01:17:18] std/os/raw/enum.c_void.html:8: broken link - std/std/primitive.never.html
[01:17:18] std/os/raw/index.html:13: broken link - std/std/primitive.pointer.html
[01:17:29] thread 'main' panicked at 'found some broken links', tools/linkchecker/main.rs:49:9
[01:17:29] note: Run with `RUST_BACKTRACE=1` for a backtrace.

It seems like it's only complaining about the re-export in std::os::raw, so i would suggest putting #[doc(no_inline)] just on that one.


What's happening here is that the link you gave it is relative to its file path. This enum appears in three places in this PR:

  • core::ffi
  • std::ffi
  • std::os::raw

Note that the module path for that last one is longer than the other two. This means that it has one more folder parent to pass through with .. to get back to the doc root. Sadly, this means that it's impossible to use the same link in all three places and still have it be valid.

(Strictly speaking, this is what "intra-doc links" were made to fix, but i'm not sure the primitive link will totally work out? For one, you'd need to add the reference into this array, but also, the primitive docs aren't even available in libcore! We'd have to fix rustdoc to make sure the link is handled correctly.)

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 13, 2018

Contributor

@QuietMisdreavus if we make std::os::raw::c_void (which is now a pub use reexport) not be documented inline (only be a link to core::ffi::c_void, which is documented):

  • Would this fix the directory nesting level problem?
  • Would this be acceptable, in terms of how we want the docs to look like?
  • Would #[doc(no_inline)] be enough to achieve this?
Contributor

SimonSapin commented Sep 13, 2018

@QuietMisdreavus if we make std::os::raw::c_void (which is now a pub use reexport) not be documented inline (only be a link to core::ffi::c_void, which is documented):

  • Would this fix the directory nesting level problem?
  • Would this be acceptable, in terms of how we want the docs to look like?
  • Would #[doc(no_inline)] be enough to achieve this?
@QuietMisdreavus

This comment has been minimized.

Show comment
Hide comment
@QuietMisdreavus

QuietMisdreavus Sep 13, 2018

Member

@SimonSapin:

  • Yes, because now the links are not being used in the std::os::raw location, and the other two have the same level of nesting.

  • In terms of "how we want them to look like", i think it would work out, though i'm welcome to a second opinion from @rust-lang/docs. The idea here is that we're moving the "canonical" location for it into libcore (which is where it would start linking). Any code written can use this location just fine (in fact it must, since this used to be its "canonical" location), but it's now available in more places, and the docs can reflect that.

  • Yes. #[doc(no_inline)], when applied to a pub use re-export, tells rustdoc "don't copy in the docs for this item; render the pub use statement into the module instead".

    (For posterity: The method rustdoc uses to determine whether to "inline" a re-export is something like this: If the "original declaration" of the item is both crate-local and public, then link to that location. Otherwise, copy the docs inline. Applying #[doc(inline)] or #[doc(no_inline)] to the declaration overrides this behavior.)

Member

QuietMisdreavus commented Sep 13, 2018

@SimonSapin:

  • Yes, because now the links are not being used in the std::os::raw location, and the other two have the same level of nesting.

  • In terms of "how we want them to look like", i think it would work out, though i'm welcome to a second opinion from @rust-lang/docs. The idea here is that we're moving the "canonical" location for it into libcore (which is where it would start linking). Any code written can use this location just fine (in fact it must, since this used to be its "canonical" location), but it's now available in more places, and the docs can reflect that.

  • Yes. #[doc(no_inline)], when applied to a pub use re-export, tells rustdoc "don't copy in the docs for this item; render the pub use statement into the module instead".

    (For posterity: The method rustdoc uses to determine whether to "inline" a re-export is something like this: If the "original declaration" of the item is both crate-local and public, then link to that location. Otherwise, copy the docs inline. Applying #[doc(inline)] or #[doc(no_inline)] to the declaration overrides this behavior.)

@IsaacWoods

This comment has been minimized.

Show comment
Hide comment
@IsaacWoods

IsaacWoods Sep 14, 2018

Contributor

@SimonSapin @QuietMisdreavus thank you for your help, linkchecker is now passing. Does anything else need to be done for this PR, maybe a squash?

Contributor

IsaacWoods commented Sep 14, 2018

@SimonSapin @QuietMisdreavus thank you for your help, linkchecker is now passing. Does anything else need to be done for this PR, maybe a squash?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 14, 2018

Contributor

@IsaacWoods Yes, please squash into one commit and I’ll r+. Thanks!

Contributor

SimonSapin commented Sep 14, 2018

@IsaacWoods Yes, please squash into one commit and I’ll r+. Thanks!

@rfcbot

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Sep 15, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

rfcbot commented Sep 15, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster
Member

shepmaster commented Sep 16, 2018

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Sep 16, 2018

Contributor

Oops I didn’t realize the squash was done.

Looks good, thanks!

@bors r+

Contributor

SimonSapin commented Sep 16, 2018

Oops I didn’t realize the squash was done.

Looks good, thanks!

@bors r+

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 16, 2018

Contributor

📌 Commit 23e345b has been approved by SimonSapin

Contributor

bors commented Sep 16, 2018

📌 Commit 23e345b has been approved by SimonSapin

@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 16, 2018

Contributor

⌛️ Testing commit 23e345b with merge 5aac93c...

Contributor

bors commented Sep 16, 2018

⌛️ Testing commit 23e345b with merge 5aac93c...

bors added a commit that referenced this pull request Sep 16, 2018

Auto merge of #53910 - IsaacWoods:unify_cvoid, r=SimonSapin
Move std::os::raw::c_void into libcore and re-export in libstd

Implements the first part of [RFC 2521](rust-lang/rfcs#2521).

cc #53856
@bors

This comment has been minimized.

Show comment
Hide comment
@bors

bors Sep 17, 2018

Contributor

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

Contributor

bors commented Sep 17, 2018

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

@bors bors merged commit 23e345b into rust-lang:master Sep 17, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@rust-highfive

This comment has been minimized.

Show comment
Hide comment
@rust-highfive

rust-highfive Sep 17, 2018

Collaborator

📣 Toolstate changed by rust-lang/rust#53910!

Tested on commit 5aac93c.
Direct link to PR: #53910

💔 clippy-driver on windows: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).

Collaborator

rust-highfive commented Sep 17, 2018

📣 Toolstate changed by rust-lang/rust#53910!

Tested on commit 5aac93c.
Direct link to PR: #53910

💔 clippy-driver on windows: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Sep 17, 2018

📣 Toolstate changed by rust-lang/rust#53910!
Tested on commit rust-lang/rust@5aac93c.
Direct link to PR: <rust-lang/rust#53910>

💔 clippy-driver on windows: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → test-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).

flip1995 added a commit to flip1995/rust-clippy that referenced this pull request Sep 17, 2018

Fix c_void path
This got changed in rust-lang/rust#53910

bors added a commit that referenced this pull request Sep 17, 2018

Auto merge of #54293 - flip1995:clippyup, r=Manishearth
Update Clippy

Fix Clippy test-fail due to #53910

r? @Manishearth @SimonSapin

@IsaacWoods IsaacWoods deleted the IsaacWoods:unify_cvoid branch Sep 17, 2018

bors added a commit to rust-lang/libc that referenced this pull request Sep 19, 2018

Auto merge of #1082 - IsaacWoods:core_cvoid, r=alexcrichton
Re-export core::ffi::c_void if it exists

This is the second part of the implementation of [RFC 2521](rust-lang/rfcs#2521), replacing the definition of `c_void` in libc with a re-export of the type from `core::ffi::c_void` on builds it exists for.

This uses the re-export for rustc version `1.31.0` or greater, as `1.30.x` was the current nightly when [the PR for the changes to libcore and libstd](rust-lang/rust#53910) was merged, so I'm assuming the first nightly they will appear in will be `1.31.0`; is this acceptable?

cc rust-lang/rust#53856
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment