From 68914f20959df94a8f557cfb99e793e01fb7bc83 Mon Sep 17 00:00:00 2001
From: Tomoki Nakagawa <tomokinat@google.com>
Date: Thu, 11 Apr 2024 14:58:40 +0900
Subject: [PATCH] Correct broken link in core::pin doc

---
 library/core/src/pin.rs | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/library/core/src/pin.rs b/library/core/src/pin.rs
index e843a5d5790..c18dbafff16 100644
--- a/library/core/src/pin.rs
+++ b/library/core/src/pin.rs
@@ -379,11 +379,11 @@
 //!
 //! Exposing access to the inner field which you want to remain pinned must then be carefully
 //! considered as well! Remember, exposing a method that gives access to a
-//! <code>[Pin]<[&mut] InnerT>></code> where `InnerT: [Unpin]` would allow safe code to trivially
-//! move the inner value out of that pinning pointer, which is precisely what you're seeking to
-//! prevent! Exposing a field of a pinned value through a pinning pointer is called "projecting"
-//! a pin, and the more general case of deciding in which cases a pin should be able to be
-//! projected or not is called "structural pinning." We will go into more detail about this
+//! <code>[Pin]<[&mut] InnerT>></code> where <code>InnerT: [Unpin]</code> would allow safe code to
+//! trivially move the inner value out of that pinning pointer, which is precisely what you're
+//! seeking to prevent! Exposing a field of a pinned value through a pinning pointer is called
+//! "projecting" a pin, and the more general case of deciding in which cases a pin should be able
+//! to be projected or not is called "structural pinning." We will go into more detail about this
 //! [below][structural-pinning].
 //!
 //! # Examples of address-sensitive types