Auto merge of rust-lang#2202 - InfRandomness:infrandomness/rustdoc-fixes, r=RalfJung

Fix rustdoc warnings

This fixes the rustdoc warnings presented by the tool

Author: bors

src/data_race.rs

@@ -1,11 +1,11 @@
 //! Implementation of a data-race detector using Lamport Timestamps / Vector-clocks
 //! based on the Dynamic Race Detection for C++:
-//! https://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2017/POPL.pdf
+//! <https://www.doc.ic.ac.uk/~afd/homepages/papers/pdfs/2017/POPL.pdf>
 //! which does not report false-positives when fences are used, and gives better
 //! accuracy in presence of read-modify-write operations.
 //!
 //! The implementation contains modifications to correctly model the changes to the memory model in C++20
-//! regarding the weakening of release sequences: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0982r1.html.
+//! regarding the weakening of release sequences: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0982r1.html>.
 //! Relaxed stores now unconditionally block all currently active release sequences and so per-thread tracking of release
 //! sequences is not needed.
 //!
@@ -15,7 +15,7 @@
 //! This does not explore weak memory orders and so can still miss data-races
 //! but should not report false-positives
 //!
-//! Data-race definition from(https://en.cppreference.com/w/cpp/language/memory_model#Threads_and_data_races):
+//! Data-race definition from(<https://en.cppreference.com/w/cpp/language/memory_model#Threads_and_data_races>):
 //! a data race occurs between two memory accesses if they are on different threads, at least one operation
 //! is non-atomic, at least one operation is a write and neither access happens-before the other. Read the link
 //! for full definition.
@@ -24,7 +24,7 @@
 //! because it only re-uses vector indexes once all currently-active (not-terminated) threads have an internal
 //! vector clock that happens-after the join operation of the candidate thread. Threads that have not been joined
 //! on are not considered. Since the thread's vector clock will only increase and a data-race implies that
-//! there is some index x where clock[x] > thread_clock, when this is true clock[candidate-idx] > thread_clock
+//! there is some index x where clock\[x\] > thread_clock, when this is true clock\[candidate-idx\] > thread_clock
 //! can never hold and hence a data-race can never be reported in that vector index again.
 //! This means that the thread-index can be safely re-used, starting on the next timestamp for the newly created
 //! thread.

src/shims/tls.rs

@@ -135,7 +135,7 @@ impl<'tcx> TlsData<'tcx> {
     /// [`_tlv_atexit`
     /// implementation](https://github.com/opensource-apple/dyld/blob/195030646877261f0c8c7ad8b001f52d6a26f514/src/threadLocalVariables.c#L389):
     ///
-    ///     // NOTE: this does not need locks because it only operates on current thread data
+    /// NOTE: this does not need locks because it only operates on current thread data
     pub fn set_macos_thread_dtor(
         &mut self,
         thread: ThreadId,
@@ -347,7 +347,7 @@ pub trait EvalContextExt<'mir, 'tcx: 'mir>: crate::MiriEvalContextExt<'mir, 'tcx
     /// Note: we consistently run TLS destructors for all threads, including the
     /// main thread. However, it is not clear that we should run the TLS
     /// destructors for the main thread. See issue:
-    /// https://github.com/rust-lang/rust/issues/28129.
+    /// <https://github.com/rust-lang/rust/issues/28129>.
     fn schedule_next_tls_dtor_for_active_thread(&mut self) -> InterpResult<'tcx> {
         let this = self.eval_context_mut();
         let active_thread = this.get_active_thread();

src/stacked_borrows.rs

@@ -945,7 +945,7 @@ pub trait EvalContextExt<'mir, 'tcx: 'mir>: crate::MiriEvalContextExt<'mir, 'tcx
     /// it does not alias with anything.
     ///
     /// This is a HACK because there is nothing in MIR that would make the retag
-    /// explicit. Also see https://github.com/rust-lang/rust/issues/71117.
+    /// explicit. Also see <https://github.com/rust-lang/rust/issues/71117>.
     fn retag_return_place(&mut self) -> InterpResult<'tcx> {
         let this = self.eval_context_mut();
         let return_place = this.frame_mut().return_place;