chore(CI): add cargo doc step to CI

.github/workflows/CI.yml

@@ -30,7 +30,6 @@ jobs:
           command: fmt
           args: --all -- --check
 
-
   test:
     name: Test ${{ matrix.rust }} on ${{ matrix.os }}
     needs: [style]
@@ -96,3 +95,24 @@ jobs:
         with:
           command: test
           args: --benches ${{ matrix.features }}
+
+  doc:
+    name: Build docs
+    needs: [style, test]
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v1
+
+      - name: Install Rust
+        uses: actions-rs/toolchain@v1
+        with:
+          profile: minimal
+          toolchain: nightly
+          override: true
+
+      - name: cargo doc
+        uses: actions-rs/cargo@v1
+        with:
+          command: rustdoc
+          args: -- -D intra-doc-link-resolution-failure

src/body/body.rs

@@ -160,7 +160,7 @@ impl Body {
 
     /// Converts this `Body` into a `Future` of a pending HTTP upgrade.
     ///
-    /// See [the `upgrade` module](::upgrade) for more.
+    /// See [the `upgrade` module](crate::upgrade) for more.
     pub fn on_upgrade(self) -> OnUpgrade {
         self.extra
             .map(|ex| ex.on_upgrade)
@@ -496,7 +496,7 @@ impl Sender {
     ///
     /// This is mostly useful for when trying to send from some other thread
     /// that doesn't have an async context. If in an async context, prefer
-    /// [`send_data`][] instead.
+    /// `send_data()` instead.
     pub fn try_send_data(&mut self, chunk: Bytes) -> Result<(), Bytes> {
         self.tx
             .try_send(Ok(chunk))

src/body/mod.rs

@@ -1,13 +1,13 @@
 //! Streaming bodies for Requests and Responses
 //!
-//! For both [Clients](::client) and [Servers](::server), requests and
+//! For both [Clients](crate::client) and [Servers](crate::server), requests and
 //! responses use streaming bodies, instead of complete buffering. This
 //! allows applications to not use memory they don't need, and allows exerting
 //! back-pressure on connections by only reading when asked.
 //!
 //! There are two pieces to this in hyper:
 //!
-//! - **The [`HttpBody`](body::HttpBody) trait** describes all possible bodies.
+//! - **The [`HttpBody`](HttpBody) trait** describes all possible bodies.
 //!   hyper allows any body type that implements `HttpBody`, allowing
 //!   applications to have fine-grained control over their streaming.
 //! - **The [`Body`](Body) concrete type**, which is an implementation of

src/client/connect/dns.rs

@@ -2,7 +2,7 @@
 //!
 //! This module contains:
 //!
-//! - A [`GaiResolver`](dns::GaiResolver) that is the default resolver for the
+//! - A [`GaiResolver`](GaiResolver) that is the default resolver for the
 //!   `HttpConnector`.
 //! - The `Name` type used as an argument to custom resolvers.
 //!

src/client/connect/mod.rs

@@ -67,12 +67,12 @@
 //! ```
 //!
 //!
-//! [`HttpConnector`]: hyper::client::HttpConnector
-//! [`Service`]: hyper::service::Service
+//! [`HttpConnector`]: HttpConnector
+//! [`Service`]: crate::service::Service
 //! [`Uri`]: http::Uri
 //! [`AsyncRead`]: tokio::io::AsyncRead
 //! [`AsyncWrite`]: tokio::io::AsyncWrite
-//! [`Connection`]: hyper::client::connect::Connection
+//! [`Connection`]: Connection
 use std::fmt;
 
 use ::http::Response;

src/client/mod.rs

@@ -3,7 +3,7 @@
 //! There are two levels of APIs provided for construct HTTP clients:
 //!
 //! - The higher-level [`Client`](Client) type.
-//! - The lower-level [`conn`](client::conn) module.
+//! - The lower-level [`conn`](conn) module.
 //!
 //! # Client
 //!

src/server/conn.rs

@@ -105,8 +105,11 @@ pub struct Connecting<I, F, E = Exec> {
 #[pin_project]
 #[derive(Debug)]
 pub(super) struct SpawnAll<I, S, E> {
+    // TODO: re-add `pub(super)` once rustdoc can handle this.
+    //
+    // See https://github.com/rust-lang/rust/issues/64705
     #[pin]
-    pub(super) serve: Serve<I, S, E>,
+    pub serve: Serve<I, S, E>,
 }
 
 /// A future binding a connection with a Service.
@@ -348,7 +351,7 @@ impl<E> Http<E> {
         }
     }
 
-    /// Bind a connection together with a [`Service`](::service::Service).
+    /// Bind a connection together with a [`Service`](crate::service::Service).
     ///
     /// This returns a Future that must be polled in order for HTTP to be
     /// driven on the connection.
@@ -570,7 +573,7 @@ where
 
     /// Enable this connection to support higher-level HTTP upgrades.
     ///
-    /// See [the `upgrade` module](::upgrade) for more.
+    /// See [the `upgrade` module](crate::upgrade) for more.
     pub fn with_upgrades(self) -> UpgradeableConnection<I, S, E>
     where
         I: Send,

src/server/mod.rs

@@ -6,12 +6,12 @@
 //! There are two levels of APIs provide for constructing HTTP servers:
 //!
 //! - The higher-level [`Server`](Server) type.
-//! - The lower-level [`conn`](server::conn) module.
+//! - The lower-level [`conn`](conn) module.
 //!
 //! # Server
 //!
 //! The [`Server`](Server) is main way to start listening for HTTP requests.
-//! It wraps a listener with a [`MakeService`](::service), and then should
+//! It wraps a listener with a [`MakeService`](crate::service), and then should
 //! be executed to start serving requests.
 //!
 //! [`Server`](Server) accepts connections in both HTTP1 and HTTP2 by default.

src/service/mod.rs

@@ -1,6 +1,6 @@
 //! Asynchronous Services
 //!
-//! A [`Service`](service::Service) is a trait representing an asynchronous
+//! A [`Service`](Service) is a trait representing an asynchronous
 //! function of a request to a response. It's similar to
 //! `async fn(Request) -> Result<Response, Error>`.
 //!
@@ -22,11 +22,11 @@
 //! connection will receive.
 //!
 //! While it's possible to implement `Service` for a type manually, the helper
-//! [`service_fn`](service::service_fn) should be sufficient for most cases.
+//! [`service_fn`](service_fn) should be sufficient for most cases.
 //!
 //! # MakeService
 //!
-//! Since a `Service` is bound to a single connection, a [`Server`](::Server)
+//! Since a `Service` is bound to a single connection, a [`Server`](crate::Server)
 //! needs a way to make them as it accepts connections. This is what a
 //! `MakeService` does.
 //!