nagai/fune
3
0
Fork 0
forked from mirrors/gecko-dev
Code Pull requests Activity

Bug 1657926 - firefox doc: fix some warnings r=championshuttler

Browse source 
Differential Revision: https://phabricator.services.mozilla.com/D86732
This commit is contained in:
Sylvestre Ledru 2020-08-11 23:20:25 +00:00
parent 08ed820595
commit 5ea6c250c3
10 changed files with 27 additions and 27 deletions
repo.diff.show_diff_stats Download patch file Download diff file Expand all files Collapse all files

2
docs/code-quality/lint/linters/l10n.rst
View file

@ -13,7 +13,7 @@ still in use in a stable channel with a different value.
The warnings on string ID changes get reported on phabricator, but they're
not making the build fail. To find out when to change IDs and when not to,
read the :doc:`Lifecycle & Workflow </intl/localization>` section in the
read the :ref:`Lifecycle & Workflow <Localization>` section in the
localization documentation.
Run Locally

8
docs/setup/linux_32bit_build_on_64bit_OS.rst
View file

@ -7,7 +7,7 @@ Instructions for Fedora 20 and 19
First ensure that your compiler toolchain and Gecko build dependencies
are installed.
.. code:: brush:
.. code::
sudo yum install \
ccache cmake gcc gcc-c++ glibc-devel.i686 \
@ -30,7 +30,7 @@ are installed.
Then you need to use a .mozconfig that looks like the following example.
.. code:: brush:
.. code::
# Flags set for targeting x86.
export CROSS_COMPILE=1
@ -63,7 +63,7 @@ These steps were verified to work as of June 2020
#. Install 32-bit dependencies with the following command (this shouldn't try to
remove packages. If this is the case, those instructions won't work as-is):
.. code:: syntaxbox
.. code::
sudo apt install gcc-multilib g++-multilib libdbus-glib-1-dev:i386 \
libgtk2.0-dev:i386 libgtk-3-dev:i386 libpango1.0-dev:i386 libxt-dev:i386 \
@ -72,7 +72,7 @@ These steps were verified to work as of June 2020
5. Create a file called ``mozconfig`` in the top-level directory of you
``mozilla-central`` checkout, containing at least the following:
.. code:: syntaxbox
.. code::
ac_add_options --target=i686

12
docs/setup/macos_build.rst
View file

@ -233,7 +233,7 @@ page <http://www.macports.org/install.php>`_, download the .dmg for
your platform, and install it. If you already have MacPorts installed,
ensure it is up to date by running:
.. code:: eval
.. code::
sudo port selfupdate
sudo port sync
@ -249,7 +249,7 @@ Common errors include:
Use MacPorts to install the packages needed for building Firefox:
.. code:: eval
.. code::
sudo port install libidl autoconf213 yasm python27 py27-gnureadline
@ -331,7 +331,7 @@ current one with the contents of the remote repository.
Below command will take many minutes to run, as it will be copying a
couple hundred megabytes of data over the internet.
.. code:: syntaxbox
.. code::
hg clone https://hg.mozilla.org/mozilla-central/
cd mozilla-central
@ -348,7 +348,7 @@ Build Options <https://developer.mozilla.org/en/Configuring_Build_Options>`_.
To get started quickly, create the file with the following contents:
.. code:: eval
.. code::
# Define where build files should go. This places them in the directory
# "obj-ff-dbg" under the current source directory
@ -366,7 +366,7 @@ that is not the case, you need to set CC and CXX. For instance, if you
installed Clang 9 via Homebrew, then you need to have this in your
``mozconfig``:
.. code:: eval
.. code::
CC=clang-9
CXX=clang++-9
@ -374,7 +374,7 @@ installed Clang 9 via Homebrew, then you need to have this in your
If you installed Autoconf 2.13 with the Homebrew recipe linked above,
you may need to add the following to your ``mozconfig``:
.. code:: eval
.. code::
mk_add_options AUTOCONF=/usr/local/Cellar/autoconf@2.13/2.13/bin/autoconf213

18
js/src/doc/build.rst
View file

@ -34,7 +34,7 @@ have.
A basic ``MOZCONFIG`` file for doing a debug build, put into ``$HOME/mozconfigs/debug`` looks like this
.. code:: eval
.. code::
# Build only the JS shell
ac_add_options --enable-application=js
@ -46,7 +46,7 @@ A basic ``MOZCONFIG`` file for doing a debug build, put into ``$HOME/mozconfigs/
To activate a particular ``MOZCONFIG``, set the environment variable:
.. code:: eval
.. code::
export MOZCONFIG=$HOME/mozconfigs/debug
@ -57,7 +57,7 @@ Once you have activated a ``MOZCONFIG`` by setting the environment variable
you can then ask ``mach``, located in the top directory of your checkout,
to do your build:
.. code:: eval
.. code::
$ cd <path to mozilla-central>
$ ./mach build
@ -91,7 +91,7 @@ Testing
Once built, you can then use ``mach`` to run the ``jit-tests``:
.. code:: eval
.. code::
$ ./mach jit-test
@ -102,7 +102,7 @@ To switch to an optimized build, one need only have an optimized build ``MOZCONF
and then activate it. An example ``$HOME/mozconfigs/optimized`` ``MOZCONFIG``
looks like this:
.. code:: eval
.. code::
# Build only the JS shell
ac_add_options --enable-application=js
@ -138,14 +138,14 @@ hello-world program.
You will also need the appropriate Rust compiler target support installed. For
example:
.. code:: eval
.. code::
$ rustup target add aarch64-unknown-linux-gnu
Once you have these prerequisites installed, you simply need to set a few
environment variables and configure the build appropriately:
.. code:: eval
.. code::
$ cd js/src/
$ export CC=aarch64-linux-gnu-gcc # adjust for target as appropriate.
@ -182,7 +182,7 @@ shared libraries already if you cross-compiled as described above.
Then, write a small wrapper script that invokes the JS shell under Qemu. For
example:
.. code:: eval
.. code::
#!/bin/sh
@ -197,6 +197,6 @@ example:
You can then invoke this wrapper as if it were a normal JS shell, and use it
with ``jit_test.py`` to run tests:
.. code:: eval
.. code::
$ jit-test/jit_test.py ./js-cross-wrapper

2
taskcluster/docs/try.rst
View file

@ -65,7 +65,7 @@ at the root of the source dir. The JSON object in this file contains a
Very simply, this will run any task label that gets passed in as well as their
dependencies. While it is possible to manually commit this file and push to
try, it is mainly meant to be a generation target for various :doc:`tryselect </tools/try>`
try, it is mainly meant to be a generation target for various :ref:`try server <Try Server>`
choosers. For example:
.. parsed-literal::

2
toolkit/components/crashes/docs/index.rst
View file

@ -18,7 +18,7 @@ From there, you can access and manipulate crash data.
The crash manager stores statistical information about crashes as well as
detailed information for both browser and content crashes. The crash manager
automatically detects new browser crashes at startup by scanning for
:ref:`crash-events`. Content process crash information on the other hand is
:ref:`Crash Events`. Content process crash information on the other hand is
provided externally.
Other Documents

2
toolkit/components/telemetry/docs/data/core-ping.rst
View file

@ -24,7 +24,7 @@ ping”, not total for the whole application lifetime.
Structure:
.. code-block:: js
.. code-block:: javascript
{
"v": 10, // ping format version

4
tools/fuzzing/docs/fuzzing_interface.rst
View file

@ -161,7 +161,7 @@ non-determinism and loss of performance.
If you are unsure if the fuzzing interface is the right approach for you or you
require help in evaluating what could be done for your particular task, please
don't hestitate to :ref:`contact us <Fuzzing#Contact Us>`.
don't hestitate to :ref:`contact us <Fuzzing#contact-us>`.
Develop the fuzzing code
@ -309,7 +309,7 @@ reduce the amount of noise that libFuzzer sees.
Build your code
^^^^^^^^^^^^^^^
See the :ref:`Build instructions above <Build Requirements>` for instructions
See the :ref:`Build instructions above <Local build requirements and flags>` for instructions
how to modify your ``.mozconfig`` to create the appropriate build.

2
tools/sanitizer/docs/asan_nightly.rst
View file

@ -26,7 +26,7 @@ update check or confirm that you run the latest version).
If you came here looking for regular ASan builds (e.g. for fuzzing or
as a developer to reproduce a crash), you should probably go to the
:ref:`Firefox and Address Sanitizer` doc instead.
:ref:`Address Sanitizer` doc instead.
.. _Requirements:

2
tools/tryselect/docs/tasks.rst
View file

@ -2,7 +2,7 @@ Task Generation
===============
Many selectors (including ``chooser``, ``coverage`` and ``fuzzy``) source their available tasks
directly from the :doc:`taskgraph </taskcluster/taskcluster/index>` module by building the taskgraph
directly from the :ref:`taskgraph <TaskCluster Task-Graph Generation>` module by building the taskgraph
locally. This means that the list of available tasks will never be stale. While this is very
powerful, it comes with a large enough performance cost to get annoying (around twenty seconds).