Remove confusing comment about ideally using `!` for `c_void`

Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.

Also document in addition that newtype wrappers around `c_void` are not
recommended for representing opaque types (as a workaround for `extern
type` not being stable) but instead refer to the Nomicon.

diff --git a/src/libcore/ffi.rs b/src/libcore/ffi.rs
index d7a112eb90df84b124718b6b5182a903b6ef579c..02e92af853452f14316925d017813c8bbb484fc6 100644 (file)
--- a/src/libcore/ffi.rs
+++ b/src/libcore/ffi.rs
@@ -13,11 +13,12 @@
 /// and `*mut c_void` is equivalent to C's `void*`. That said, this is
 /// *not* the same as C's `void` return type, which is Rust's `()` type.
 ///
-/// Ideally, this type would be equivalent to [`!`], but currently it may
-/// be more ideal to use `c_void` for FFI purposes.
+/// To model pointers to opaque types in FFI, until `extern type` is
+/// stabilized, it is recommended to use a newtype wrapper around an empty
+/// byte array. See the [Nomicon] for details.
 ///
-/// [`!`]: ../../std/primitive.never.html
 /// [pointer]: ../../std/primitive.pointer.html
+/// [Nomicon]: https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs
 // N.B., for LLVM to recognize the void pointer type and by extension
 //     functions like malloc(), we need to have it represented as i8* in
 //     LLVM bitcode. The enum used here ensures this and prevents misuse