Bug 1714788 - Fixed more Sphinx warnings in 'mach doc' r=sylvestre DONTBUILD

Differential Revision: https://phabricator.services.mozilla.com/D117225

docs/performance/tools_power_rapl.md

@@ -12,7 +12,7 @@ of this document easier to understand.
 
 ## Invocation
 
-First, do a [standard build of Firefox](setup/index.html).
+First, do a [standard build of Firefox](../setup/index.html).
 
 ### Mac
 

toolkit/components/glean/docs/dev/code_organization.md

@@ -56,7 +56,7 @@ This module is responsible for
 * exposing a specific metric API in Rust
 * wrapping metric implementations for handling IPC
 * exposing FFI functionality to implement other language APIs on top.
-  See also [Adding a New Metric Type](new_metric_type.md).
+  See also [Adding a New Metric Type](new_metric_types.md).
 
 It calls into `glean` (the Glean SDK Rust Language Binding) for:
 

toolkit/components/glean/docs/dev/ipc.md

@@ -114,4 +114,4 @@ handed off to C++, passed over IPC,
 then given back to `bincode` in Rust on the Parent.
 
 Rust is then responsible for turning the pending data into
-[metric API](api.md) calls on the metrics in the parent process.
+[metric API](../user/api.md) calls on the metrics in the parent process.

toolkit/components/glean/docs/dev/new_metric_types.md

@@ -101,7 +101,7 @@ they're both implemented in C++ and share much of their implementation.
 The overall design is to build the C++ API atop the Multi-Language Architecture's
 (MLA's) FFI, then build the JS API atop the C++ API.
 This allows features like the
-[Glean Interface For Firefox Telemetry (GIFFT)](gifft.md)
+[Glean Interface For Firefox Telemetry (GIFFT)](../user/gifft.md)
 that target only C++ and JS to be more simply implemented in the C++ layer.
 Exceptions to this (where the JS uses the FFI directly) are discouraged.
 
@@ -224,7 +224,7 @@ There are four pieces to this:
   add your sub metric type's map as a list item in the `submetric_maps` `mod` of
   [`rust.jinja2`](https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/glean/build_scripts/glean_parser_ext/templates/rust.jinja2).
 - Following the pattern of the others, add a `fog_{your labeled metric name here}_get()` FFI API to
-  [`api/src/ffi/mod.rs`]().
+  `api/src/ffi/mod.rs`.
   This is what C++ and JS will use to allocate and retrieve sub metric instances by id.
 
 #### C++

toolkit/components/glean/docs/user/new_definitions_file.md

@@ -13,7 +13,7 @@ with some few twists.
 
 Firefox Desktop is made of multiple processes.
 You can record data from any process in Firefox Desktop
-[subject to certain conditions](ipc.md).
+[subject to certain conditions](../dev/ipc.md).
 
 If you will be recording data to this metric in multiple processes,
 you should make yourself aware of those conditions.

tools/fuzzing/docs/fuzzing_interface.rst

@@ -93,6 +93,8 @@ bug you are working on and ``test.bin`` is the attached testcase.
 If the CI builds don't meet your requirements and you need a local build instead,
 you can follow the steps below to create one:
 
+.. _Local build requirements and flags:
+
 Local build requirements and flags
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -402,6 +404,7 @@ What this does is
    tool
 -  write statistics to the ``libfuzzer-stunparser.stats`` file
 
+.. _JS Engine Specifics:
 
 JS Engine Specifics
 ~~~~~~~~~~~~~~~~~~~

tools/fuzzing/docs/index.rst

@@ -60,7 +60,7 @@ Random API Usage
 
 Randomly testing APIs is especially helpful with parts of software that
 expose a well-defined interface (see also :ref:`Well-defined
-behavior and Safety`). If this interface is additionally exposed to
+behavior and Safety <Well defined behaviour and safety>`). If this interface is additionally exposed to
 untrusted parties/content, then this is a strong sign that random API
 testing would be worthwhile here, also for security reasons. APIs can be
 anything from C++ layer code to APIs offered in the browser.
@@ -82,7 +82,7 @@ example an automated browser that surfs through the web and randomly
 performs actions such as scrolling, zooming and clicking links. The nice
 thing about this approach is that you likely find many issues that the
 end-user also experiences. However, this approach typically suffers from
-bad reproducibility (see also :ref:`Reproducibility`) and is therefore
+bad reproducibility (see also :ref:`Reproducibility <Reproducibility>`) and is therefore
 often of limited use.
 
 An example for a fuzzing tool using this technique is `Android
@@ -101,7 +101,7 @@ time there are two common things you will be confronted with:
 find all sorts of bugs in various corners of your component, even
 obscure ones. This automatically leads to a larger number of bugs that
 either don’t seem to be bugs (see also the :ref:`Well-defined behavior and
-safety` section below) or that don’t seem to be important bugs.
+safety <Well defined behaviour and safety>` section below) or that don’t seem to be important bugs.
 
 Fixing these bugs is still important for the fuzzers because ignoring them
 in fuzzing costs resources (performance, human resources) and might even
@@ -267,6 +267,8 @@ External I/O like network or file interactions are bad for performance
 and can introduce additional non-determinism. Providing interfaces to
 process data directly from memory instead is usually much more helpful.
 
+.. _Well defined behaviour and safety:
+
 Well-defined Behavior and Safety
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -289,6 +291,8 @@ crashes. However, keep in mind that crashes in general can be disruptive
 to the fuzzing process. Performance is an important aspect of fuzzing
 and frequent crashes can severely degrade performance.
 
+.. _Reproducibility:
+
 Reproducibility
 ~~~~~~~~~~~~~~~
 

tools/moztreedocs/docs/run-try-job.rst

@@ -22,4 +22,4 @@ Documentation has two try jobs associated :
 .. note::
 
    To learn more about setting up try server or
-   using a different selector head over to :ref:`try server documentation <Try Server>`
+   using a different selector head over to :ref:`try server documentation <Pushing to Try>`

tools/sanitizer/docs/asan.rst

@@ -56,7 +56,7 @@ Creating Try builds
 If for some reason you can't use the pre-built binaries mentioned in the
 previous section (e.g. you want a non-Linux build or you need to test a
 patch), you can either build Firefox yourself (see the following
-section) or use the :ref:`try server <Try Server>` to
+section) or use the :ref:`try server <Pushing to Try>` to
 create the customized build for you. Pushing to try requires L1 commit
 access. If you don't have this access yet you can request access (see
 `Becoming A Mozilla

tools/sanitizer/docs/tsan.rst

@@ -47,7 +47,7 @@ Creating Try builds
 
 If for some reason you can't use the pre-built binaries mentioned in the
 previous section (e.g. you need to test a patch), you can either build
-Firefox yourself (see the following section) or use the :ref:`try server <Try Server>`
+Firefox yourself (see the following section) or use the :ref:`try server <Pushing to Try>`
 to create the customized build for you. Pushing to try requires L1 commit
 access. If you don't have this access yet you can request access (see
 `Becoming A Mozilla
@@ -262,6 +262,8 @@ Unfortunately, the TSan algorithm does not guarantee, that a race is detected 10
 time. Intermittent failures with TSan are (to a certain degree) to be expected and the races
 involved should be filed and fixed to solve the problem.
 
+.. _Frequently Asked Questions about TSan:
+
 Frequently Asked Questions about TSan
 -------------------------------------