doc: Fix various documentation formatting warnings

doc/installation/source/windows.rst

@@ -19,7 +19,7 @@ either WSL or the Msys2/MinGW64 toolchain (installing both is not required).
 
 .. note::
   |ns3| is not fully compatible with Visual Studio IDE / MSVC compiler; only Visual Studio Code
-editor, the Msys2/MinGW64 toolchain, and WSL, as explained below.
+  editor, the Msys2/MinGW64 toolchain, and WSL, as explained below.
 
 .. _WSL2:
 

doc/manual/Makefile

@@ -78,7 +78,6 @@ SOURCEFIGS = \
 	figures/hotspot-top-down.png \
 	figures/perfetto-trace-cmake.png \
 	figures/uprof-collect-callstack.png \
-	figures/uprof-collect-callstack.png \
 	figures/uprof-profile-application.png \
 	figures/uprof-select-events.png \
 	figures/uprof-start.png \

doc/manual/source/utilities.rst

@@ -33,7 +33,7 @@ search for specific information.
 
 To run it, simply open terminal and type
 
-.. sourcecode::
+.. sourcecode:: bash
 
     $ ./ns3 run print-introspected-doxygen
 
@@ -78,7 +78,7 @@ This tool is used to benchmark the scheduler algorithms used in |ns3|.
 Command-line Arguments
 ++++++++++++++++++++++
 
-.. sourcecode::
+.. sourcecode:: bash
 
     $ ./ns3 run "bench-scheduler --help"
     bench-scheduler [Program Options] [General Arguments]
@@ -129,7 +129,7 @@ Invocation
 
 To run it, simply open the terminal and type
 
-.. sourcecode::
+.. sourcecode:: bash
 
     $ ./ns3 run bench-scheduler -- --runs=5
 
@@ -156,7 +156,7 @@ It will show something like this depending upon the scheduler being benchmarked:
 
 Suppose we had to benchmark `CalendarScheduler` instead, we would have written
 
-.. sourcecode::
+.. sourcecode:: bash
 
     $ ./ns3 run bench-scheduler -- --runs=5 --cal"
 

doc/tutorial/source/tracing.rst

@@ -1463,8 +1463,8 @@ This should also be self-explanatory.
 
 Previous versions of |ns3| declared a custom application called ``MyApp``
 for use in this program.  Current versions of |ns3| have moved this to
-a separate header file (``tutorial-app.h'') and implementation file
-(``tutorial-app.cc'').  This simple application allows the ``Socket''
+a separate header file (``tutorial-app.h``) and implementation file
+(``tutorial-app.cc``).  This simple application allows the ``Socket``
 to be created at configuration time.
 
 ::
@@ -1887,11 +1887,11 @@ Main Program
 ~~~~~~~~~~~~
 
 The main function starts off by configuring the TCP type to use a legacy
-``NewReno`` congestion control variant, with what is called the ``classic''
+``NewReno`` congestion control variant, with what is called the ``classic``
 TCP loss recovery mechanism.  When this tutorial program was originally
 written, these were the default TCP configurations, but over time,
 |ns3| TCP has evolved to use the current Linux TCP defaults of ``Cubic``
-and ``Prr'' loss recovery.  The first statements also configure the
+and ``Prr`` loss recovery.  The first statements also configure the
 command-line argument processing.
 
 ::

src/antenna/doc/source/antenna-design.rst

@@ -153,6 +153,7 @@ Derived classes must implement the following functions:
 The class PhasedArrayModel also assumes that all antenna elements are equal, a typical key assumption which allows to model the PAA field pattern as the sum of the array factor, given by the geometry of the location of the antenna elements, and the element field pattern.
 Any class derived from AntennaModel is a valid antenna element for the PhasedArrayModel, allowing for a great flexibility of the framework.
 
+.. _3gpp-antenna-model:
 
 UniformPlanarArray
 ++++++++++++++++++

src/internet/doc/tcp.rst

@@ -456,7 +456,7 @@ cwnd, 'bytes_acked' is reduced by the value of cwnd. Next, cwnd is incremented
 by a full-sized segment (SMSS).  In contrast, in ns-3 NewReno, cwnd is increased
 by (1/cwnd) with a rounding off due to type casting into int.
 
-.. code-block::
+.. code-block:: c++
    :caption: Linux Reno `cwnd` update
 
    if (m_cWndCnt >= w)
@@ -469,7 +469,7 @@ by (1/cwnd) with a rounding off due to type casting into int.
    }
 
 
-.. code-block::
+.. code-block:: c++
    :caption: New Reno `cwnd` update
 
    if (segmentsAcked > 0)
@@ -1840,7 +1840,7 @@ advertises a zero window. This can be accomplished by implementing the method
 CreateReceiverSocket, setting an Rx buffer value of 0 bytes (at line 6 of the
 following code):
 
-.. code-block::
+.. code-block:: c++
    :linenos:
    :emphasize-lines: 6,7,8
 
@@ -1987,7 +1987,7 @@ we expect the persistent timer to fire before any rWnd changes. When it fires,
 the SENDER should send a window probe, and the receiver should reply reporting
 again a zero window situation. At first, we investigates on what the sender sends:
 
-.. code-block::
+.. code-block:: c++
       :linenos:
       :emphasize-lines: 1,6,7,11
 
@@ -2020,7 +2020,7 @@ reader: edit the test, getting this value from the Attribute system), we need
 to check (line 6) between 6.0 and 7.0 simulated seconds that the probe is sent.
 Only one probe is allowed, and this is the reason for the check at line 11.
 
-.. code-block::
+.. code-block:: c++
    :linenos:
    :emphasize-lines: 6,7
 
@@ -2072,7 +2072,7 @@ the window should be greater than zero (and precisely, set to 2500):
 To be sure that the sender receives the window update, we can use the Rx
 method:
 
-.. code-block::
+.. code-block:: c++
    :linenos:
    :emphasize-lines: 5
 
@@ -2137,7 +2137,6 @@ To see INFO messages, use a combination of ./ns3 shell and gdb (really useful):
 
 .. code-block:: bash
 
-
     ./ns3 shell && gdb --args ./build/utils/ns3-dev-test-runner-debug --test-name=tcp-zero-window-test --stop-on-failure --fullness=QUICK --assert-on-failure --verbose
 
 and then, hit "Run".

src/lr-wpan/doc/lr-wpan.rst

@@ -220,7 +220,10 @@ reference packets (11 bytes MAC header + 7 bytes payload (MSDU) + FCS 2 bytes).
 have the effect to receive more packets (and at a greater distance) but it raises the probability to have dropped packets at the
 MAC layer or the probability of corrupted packets. By default, the receiver sensitivity is set to the maximum theoretical possible value of -106.58 dBm for the supported IEEE 802.15.4 O-QPSK 250kps.
 This rx sensitivity is set for the "perfect radio" which only considers the floor noise, in essence, this do not include the noise factor (noise introduced by imperfections in the demodulator chip or external factors).
-The receiver sensitivity can be changed to different values using ``SetRxSensitivity`` function in the PHY to simulate the hearing capabilities of different compliant radio transceivers (the standard minimum compliant Rx sensitivity is -85 dBm).:::
+The receiver sensitivity can be changed to different values using ``SetRxSensitivity`` function in the PHY to simulate the hearing capabilities of different compliant radio transceivers (the standard minimum compliant Rx sensitivity is -85 dBm).:
+
+::
+
                                                               (defined by the standard)
    NoiseFloor          Max Sensitivity                          Min Sensitivity
    -106.987dBm          -106.58dBm                                   -85dBm

src/propagation/doc/propagation.rst

@@ -946,7 +946,7 @@ Vehicular fast fading model
 
 The fast fading model described in Sec. 6.2.3 of TR 37.885 is based on the one
 specified in TR 38.901, whose implementation is provided in the ``spectrum`` module
-(see the :ref:`spectrum module documentation <sec-3gpp-fast-fading-model>`).
+(see the :ref:`spectrum module documentation <3gpp-fast-fading-model>`).
 This model is general and includes different parameters which can
 be tuned to simulate multiple propagation environments.
 To better model the channel dynamics in vehicular environments, TR 37.885
@@ -956,7 +956,7 @@ To select the parameters for vehicular scenarios, it is necessary to set
 the attribute "Scenario" of the class :cpp:class:`ThreeGppChannelModel` using the value
 "V2V-Urban" or "V2V-Highway".
 
-Additionally, TR 37.885 specifies a new equation to compute the Doppler component,
+edditionally, TR 37.885 specifies a new equation to compute the Doppler component,
 which accounts for the mobility of both nodes, as well as scattering
 from the environment.
 In particular, the scattering effect is considered by deviating the Doppler
@@ -978,7 +978,7 @@ We considered two communicating vehicles moving within the scenario, and
 computed the SNR experienced during the entire simulation, with a time
 resolution of 10 ms.
 The vehicles are equipped with 2x2 antenna arrays modeled using the
-:ref:`3GPP antenna model <sec-3gpp-antenna-model>`.
+:ref:`3GPP antenna model <3gpp-antenna-model>`.
 The bearing and the downtilt angles are properly configured and the
 optimal beamforming vectors are computed at the beginning of the simulation.
 

src/spectrum/doc/spectrum.rst

@@ -594,6 +594,8 @@ the given geographic origin point, and is tested in the ``rand-cart-around-geo``
 test suite by verifying that the generated points do not exceed the given
 maximum distance radius from the origin point.
 
+.. _3gpp-fast-fading-model:
+
 3GPP TR 38.901 fast fading model
 ================================
 The framework described by TR 38.901 [TR38901]_ is a 3D statistical Spatial
@@ -1042,6 +1044,3 @@ References
    Mattias Frenne, Farshid Ghasemzadeh, Måns Hagström et al. Advanced Antenna Systems
    for 5G Network Deployments: Bridging the Gap Between Theory and Practice.
    Academic Press, 2020.
-
-.. [TR38901] 3GPP. 2018. TR 38.901. Study on channel for frequencies from 0.5 to
-   100 GHz. V.15.0.0. (2018-06).