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

IsaacWoods · 2018-09-02T21:13:07Z

Implements the first part of RFC 2521.

rust-highfive · 2018-09-02T21:13:09Z

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

rust-highfive · 2018-09-02T21:35:22Z

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 · 2018-09-03T13:09:49Z

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 · 2018-09-03T13:09:50Z

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 · 2018-09-03T16:32:49Z

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 · 2018-09-03T19:28:38Z

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 · 2018-09-04T13:22:18Z

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 · 2018-09-04T14:30:58Z

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 · 2018-09-05T15:13:55Z

@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 · 2018-09-05T16:12:09Z

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 · 2018-09-05T17:48:04Z

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

IsaacWoods · 2018-09-05T19:21:37Z

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 · 2018-09-05T19:37:11Z

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

IsaacWoods · 2018-09-05T19:51:41Z

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 · 2018-09-11T17:37:22Z

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 · 2018-09-13T15:13:05Z

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 · 2018-09-13T15:39:43Z

@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 · 2018-09-13T15:53:25Z

@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 · 2018-09-14T14:25:50Z

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

rfcbot · 2018-09-15T17:48:08Z

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

shepmaster · 2018-09-16T13:45:04Z

r? @SimonSapin

SimonSapin · 2018-09-16T15:40:56Z

Oops I didn’t realize the squash was done.

Looks good, thanks!

@bors r+

bors · 2018-09-16T15:40:57Z

📌 Commit 23e345b has been approved by SimonSapin

bors · 2018-09-16T23:13:37Z

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

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 · 2018-09-17T01:36:52Z

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

rust-highfive · 2018-09-17T01:38:11Z

📣 Toolstate changed by #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).

@Manishearth

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).

This got changed in rust-lang/rust#53910

@Manishearth

Update Clippy Fix Clippy test-fail due to #53910 r? @Manishearth @SimonSapin

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

rust-highfive assigned shepmaster Sep 2, 2018

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

SimonSapin added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Sep 3, 2018

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Sep 3, 2018

SimonSapin added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 3, 2018

rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Sep 5, 2018

rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Sep 5, 2018

SimonSapin 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-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Sep 5, 2018

rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Sep 15, 2018

rust-highfive assigned SimonSapin and unassigned shepmaster Sep 16, 2018

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 Sep 16, 2018

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

Auto merge of #53910 - IsaacWoods:unify_cvoid, r=SimonSapin

5aac93c

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 merged commit 23e345b into rust-lang:master Sep 17, 2018

bors mentioned this pull request Sep 17, 2018

libcore: Add VaList and variadic arg handling intrinsics #49878

Merged

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

Fix c_void path

a8b681c

This got changed in rust-lang/rust#53910

This was referenced Sep 17, 2018

Fix c_void path rust-lang/rust-clippy#3194

Merged

Update Clippy #54293

Merged

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

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

186fe09

Update Clippy Fix Clippy test-fail due to #53910 r? @Manishearth @SimonSapin

IsaacWoods deleted the unify_cvoid branch September 17, 2018 16:04

IsaacWoods mentioned this pull request Sep 17, 2018

Re-export core::ffi::c_void if it exists rust-lang/libc#1082

Merged

Centril mentioned this pull request Sep 19, 2018

Tracking issue for RFC 2521, "Unify std::os::raw::c_void and libc::c_void via libcore" #53856

Closed

3 tasks

gnzlbg mentioned this pull request Nov 22, 2018

0.2.44 breaks fairly recent compiler rust-lang/libc#1136

Closed

elichai mentioned this pull request Feb 18, 2019

Add no-std support rust-bitcoin/rust-secp256k1#100

Merged

hellow554 mentioned this pull request Aug 19, 2019

core::ffi::c_void is marked as "stable since 1.1", but it was added in 1.30 #63694

Closed

geofft mentioned this pull request Sep 1, 2019

Use c_void definition from libcore fishinabarrel/linux-kernel-module-rust#160

Merged

tesuji mentioned this pull request Oct 29, 2019

c_void stabilized since 1.30.0? #65922

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

IsaacWoods commented Sep 2, 2018 •

edited

Loading

rust-highfive commented Sep 2, 2018

rust-highfive commented Sep 2, 2018

SimonSapin commented Sep 3, 2018

rfcbot commented Sep 3, 2018 •

edited by dtolnay

Loading

rust-highfive commented Sep 3, 2018

rust-highfive commented Sep 3, 2018

rust-highfive commented Sep 4, 2018

SimonSapin commented Sep 4, 2018

IsaacWoods commented Sep 5, 2018

SimonSapin commented Sep 5, 2018

rfcbot commented Sep 5, 2018

IsaacWoods commented Sep 5, 2018

SimonSapin commented Sep 5, 2018

IsaacWoods commented Sep 5, 2018

TimNN commented Sep 11, 2018

QuietMisdreavus commented Sep 13, 2018

SimonSapin commented Sep 13, 2018

QuietMisdreavus commented Sep 13, 2018

IsaacWoods commented Sep 14, 2018

rfcbot commented Sep 15, 2018

shepmaster commented Sep 16, 2018

SimonSapin commented Sep 16, 2018

bors commented Sep 16, 2018

bors commented Sep 16, 2018

bors commented Sep 17, 2018

rust-highfive commented Sep 17, 2018

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

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

Conversation

IsaacWoods commented Sep 2, 2018 • edited Loading

rust-highfive commented Sep 2, 2018

rust-highfive commented Sep 2, 2018

SimonSapin commented Sep 3, 2018

rfcbot commented Sep 3, 2018 • edited by dtolnay Loading

rust-highfive commented Sep 3, 2018

rust-highfive commented Sep 3, 2018

rust-highfive commented Sep 4, 2018

SimonSapin commented Sep 4, 2018

IsaacWoods commented Sep 5, 2018

SimonSapin commented Sep 5, 2018

rfcbot commented Sep 5, 2018

IsaacWoods commented Sep 5, 2018

SimonSapin commented Sep 5, 2018

IsaacWoods commented Sep 5, 2018

TimNN commented Sep 11, 2018

QuietMisdreavus commented Sep 13, 2018

SimonSapin commented Sep 13, 2018

QuietMisdreavus commented Sep 13, 2018

IsaacWoods commented Sep 14, 2018

rfcbot commented Sep 15, 2018

shepmaster commented Sep 16, 2018

SimonSapin commented Sep 16, 2018

bors commented Sep 16, 2018

bors commented Sep 16, 2018

bors commented Sep 17, 2018

rust-highfive commented Sep 17, 2018

IsaacWoods commented Sep 2, 2018 •

edited

Loading

rfcbot commented Sep 3, 2018 •

edited by dtolnay

Loading