Bug 1749473 - fix all pygments warnings r=sylvestre

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

browser/components/newtab/docs/v2-system-addon/data_dictionary.md

@@ -130,7 +130,7 @@ Schema definitions/validations that can be used for tests can be found in `syste
 }
 ```
 
-```eval_rst
+```{eval-rst}
 +----------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+------------------+
 | KEY                        | DESCRIPTION                                                                                                                                          |                  |
 +============================+======================================================================================================================================================+==================+
@@ -319,7 +319,7 @@ but will likely be added in future versions:
 
 This encoding mapping was defined in `system-addon/lib/TelemetryFeed.jsm`
 
-```eval_rst
+```{eval-rst}
 +-------------------+------------------------+
 | Preference        | Encoded value (binary) |
 +===================+========================+

browser/components/newtab/docs/v2-system-addon/sections.md

@@ -23,7 +23,7 @@ stored as serialised JSON in the pref `{feed_pref_name}.options`, or the empty
 object if this doesn't exist. The generator returns a section configuration
 object which may have the following properties:
 
-```eval_rst
+```{eval-rst}
 +--------------------+---------------------+-------------------------------------------------------------------------------------------------------------------+
 | Property           | Type                | Description                                                                                                       |
 +====================+=====================+===================================================================================================================+

devtools/docs/contributor/backend/actor-e10s-handling.md

@@ -2,10 +2,10 @@
 
 In multi-process environments, most devtools actors are created and initialized in the child content process, to be able to access the resources they are exposing to the toolbox. But sometimes, these actors need to access things in the parent process too. Here's why and how.
 
-```warning::
-  | This documentation page is **deprecated**. setupInParent relies on the message manager which is being deprecated. Furthermore, communications between parent and content processes should be avoided for security reasons. If possible, the client should be responsible for calling actors both on the parent and content process.
-  |
-  | This page will be removed when all actors relying on this API are removed.
+```{warning}
+  This documentation page is **deprecated**. setupInParent relies on the message manager which is being deprecated. Furthermore, communications between parent and content processes should be avoided for security reasons. If possible, the client should be responsible for calling actors both on the parent and content process.
+
+  This page will be removed when all actors relying on this API are removed.
 ```
 
 ## Use case and examples
@@ -18,7 +18,7 @@ When the actor is loaded for the first time in the `DevToolsServer` running in t
 
 Example code for the actor running in the child process:
 
-```
+```js
   const {DevToolsServer} = require("devtools/server/devtools-server");
 
   // Setup the child<->parent communication only if the actor module
@@ -46,7 +46,7 @@ The `setupParentProcess` function will receive a parameter that contains a refer
 
 See below an example implementation of a `setupParent` function in the parent process:
 
-```
+```js
 exports.setupParentProcess = function setupParentProcess({ mm, prefix }) {
   // Start listening for messages from the actor in the child process.
   setMessageManager(mm);

devtools/docs/contributor/contributing/react-performance-tips.md

@@ -61,7 +61,7 @@ equivalent. You can read more on [React documentation](https://reactjs.org/docs/
 There's only one way to start a React application and trigger a first render:
 calling `ReactDOM.render`:
 
-```jsx
+```javascript
 ReactDOM.render(
   <Application content='Hello World!'/>,
   document.getElementById('root')
@@ -185,7 +185,7 @@ method with 2 parameters: the new props, and the new
 state. If this method returns false, then React will skip the render process for this
 component, **and its whole subtree**.
 
-```jsx
+```javascript
 class ComplexPanel extends React.Component {
   // Note: this syntax, new but supported by Babel, automatically binds the
   // method with the object instance.
@@ -230,7 +230,7 @@ A very common implementation of `shouldComponentUpdate` is provided by React's
 [`PureComponent`](https://reactjs.org/docs/react-api.html#reactpurecomponent):
 it will shallowly check the new props and states for reference equality.
 
-```jsx
+```javascript
 class ComplexPanel extends React.PureComponent {
   // Note: this syntax, new but supported by Babel, automatically binds the
   // method with the object instance.

devtools/docs/contributor/tests/writing-perf-tests.md

@@ -3,16 +3,12 @@
 See [DAMP Performance tests](performance-tests-damp.md) for an overall description of our performance tests.
 Here, we will describe how to write a new test and register it to run in DAMP.
 
-```note::
-  | **Reuse existing tests if possible!**
-  |
-  | If a `custom` page already exists for the tool you are testing, try to modify the existing `custom` test rather than adding a new individual test.
-  |
-  | New individual tests run separately, in new tabs, and make DAMP slower than just modifying existing tests. Complexifying `custom` test pages should also help cover more scenarios and catch more regressions. For those reasons, modifying existing tests should be the preferred way of extending DAMP coverage.
-  |
-  | `custom` tests are using complex documents that should stress a particular tool in various ways. They are all named `custom.${tool}` (for instance `custom.inspector`). The test pages for those tests can be found in [pages/custom](https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/devtools/addon/content/pages/custom).
-  |
-  | If your test case requires a dedicated document or can't run next to the other tests in the current `custom` test, follow the instructions below to add a new individual test.
+```{note}
+  **Reuse existing tests if possible!**
+  If a `custom` page already exists for the tool you are testing, try to modify the existing `custom` test rather than adding a new individual test.
+  New individual tests run separately, in new tabs, and make DAMP slower than just modifying existing tests. Complexifying `custom` test pages should also help cover more scenarios and catch more regressions. For those reasons, modifying existing tests should be the preferred way of extending DAMP coverage.
+  `custom` tests are using complex documents that should stress a particular tool in various ways. They are all named `custom.${tool}` (for instance `custom.inspector`). The test pages for those tests can be found in [pages/custom](https://searchfox.org/mozilla-central/source/testing/talos/talos/tests/devtools/addon/content/pages/custom).
+  If your test case requires a dedicated document or can't run next to the other tests in the current `custom` test, follow the instructions below to add a new individual test.
 ```
 
 This page contains the general documentation for writing DAMP tests. See also:

docs/code-quality/coding-style/css_guidelines.rst

@@ -340,7 +340,7 @@ content values (which is probably what you want), and you're going to
 want them both after the global values, so your imports will look like
 this:
 
-.. code:: xhtml
+.. code:: html
 
    <?xml-stylesheet href="chrome://global/skin/global.css" type="text/css"?>
    <?xml-stylesheet href="chrome://browser/content/path/module.css" type="text/css"?>

docs/code-quality/coding-style/svg_guidelines.rst

@@ -92,25 +92,25 @@ Whitespace examples
 
 This path:
 
-.. code:: svg
+.. code:: html
 
    <path d=" M5,5    L1,1z ">
 
 can be cut down to this:
 
-.. code:: svg
+.. code:: html
 
    <path d="M5,5 L1,1z">
 
 Similarly, this polygon:
 
-.. code:: svg
+.. code:: html
 
    <polygon points="  0,0   4,4  4,0  "/>
 
 can be cut down to this:
 
-.. code:: svg
+.. code:: html
 
    <polygon points="0,0 4,4 4,0"/>
 
@@ -297,13 +297,13 @@ Nested transforms
 Some editors use ``<g>`` tags to do nested transforms, which is usually
 not needed. You can avoid this by doing basic algebra, for example:
 
-.. code:: svg
+.. code:: xml
 
    <g transform="translate(-62, -310)"><shape transform="translate(60, 308)"/></g>
 
 can be cut down to:
 
-.. code:: svg
+.. code:: xml
 
    <shape transform="translate(-2,-2)"/>
 

docs/performance/memory/DOM_allocation_example.md

@@ -8,7 +8,7 @@ You can try out the site at
 
 It just contains a script that creates a large number of DOM nodes:
 
-``` {.brush: .js}
+```js
 var toolbarButtonCount = 20;
 var toolbarCount = 200;
 

docs/performance/memory/monster_example.md

@@ -7,7 +7,7 @@ You can try the site at
 <https://mdn.github.io/performance-scenarios/js-allocs/alloc.html>.
 Heres the code:
 
-``` {.brush: .js}
+```js
 var MONSTER_COUNT = 5000;
 var MIN_NAME_LENGTH = 2;
 var MAX_NAME_LENGTH = 48;

docs/performance/scroll-linked_effects.md

@@ -39,7 +39,7 @@ well:
 Here is an implementation of a sticky-positioning effect, where the
 \"toolbar\" div will stick to the top of the screen as you scroll down.
 
-``` {.brush: .html}
+```html
 <body style="height: 5000px" onscroll="document.getElementById('toolbar').style.top = Math.max(100, window.scrollY) + 'px'">
  <div id="toolbar" style="position: absolute; top: 100px; width: 100px; height: 20px; background-color: green"></div>
 </body>
@@ -57,7 +57,7 @@ constant moving and snapping will result in a jittery visual effect. One
 way to implement this without the scroll event listener is to use the
 CSS property designed for this purpose:
 
-``` {.brush: .html}
+```html
 <body style="height: 5000px">
  <div id="toolbar" style="position: sticky; top: 0px; margin-top: 100px; width: 100px; height: 20px; background-color: green"></div>
 </body>
@@ -72,7 +72,7 @@ Below is an implementation of scroll snapping, where the scroll position
 snaps to a particular destination when the user's scrolling stops near
 that destination.
 
-``` {.brush: .html}
+```html
 <body style="height: 5000px">
  <script>
     function snap(destination) {
@@ -104,7 +104,7 @@ Instead, using the CSS snap-points property will allow the browser to
 run the animation asynchronously, providing a smooth visual effect to
 the user.
 
-``` {.brush: .html}
+```html
 <body style="height: 5000px">
  <style>
     body, /* blink currently has bug that requires declaration on `body` */

docs/performance/tools_power_rapl.md

@@ -18,7 +18,7 @@ First, do a [standard build of Firefox](/setup/index.rst).
 
 On Mac, `rapl` can be run as follows.
 
-``` {.brush: .bash}
+```bash
 $OBJDIR/dist/bin/rapl
 ```
 
@@ -49,7 +49,7 @@ the relevant model-specific registers.
 The following is 10 seconds of output from a default invocation of
 `rapl`.
 
-``` {.brush: .bash}
+```bash
     total W = _pkg_ (cores + _gpu_ + other) + _ram_ W
 #01  5.17 W =  1.78 ( 0.12 +  0.10 +  1.56) +  3.39 W
 #02  9.43 W =  5.44 ( 1.44 +  1.20 +  2.80) +  3.98 W
@@ -81,7 +81,7 @@ Once sampling is finished --- either because the user interrupted it, or
 because the requested number of samples has been taken --- the following
 summary data is shown:
 
-``` {.brush: .bash}
+```bash
 10 samples taken over a period of 10.000 seconds
 
 Distribution of 'total' values:

docs/performance/turbostat.md

@@ -12,14 +12,14 @@ of this document easier to understand.
 
 `turbostat` must be invoked as the super-user:
 
-``` {.brush: .bash}
+```bash
 sudo turbostat
 ```
 
 If you get an error saying `"turbostat: no /dev/cpu/0/msr"`, you need to
 run the following command:
 
-```
+```bash
 sudo modprobe msr
 ```
 

testing/geckodriver/doc/Releasing.md

@@ -17,7 +17,7 @@ In any case, the steps to release geckodriver are as follows:
 geckodriver depends on a number of Rust crates that also live in
 central by using relative paths. Here an excerpt from its `Cargo.toml`:
 
-```cargo
+```ini
 [dependencies]
 …
 marionette = { path = "./marionette" }