diff --git a/browser/components/touchbar/docs/index.rst b/browser/components/touchbar/docs/index.rst index 6f11988900e9..902eb2c8496d 100644 --- a/browser/components/touchbar/docs/index.rst +++ b/browser/components/touchbar/docs/index.rst @@ -57,8 +57,7 @@ and so on. Inputs are defined in the ``gBuiltInInputs`` object `in that file`_. When creating a new object in ``gBuiltInInputs``, the available properties are documented in the JSDoc for ``TouchBarInput``: -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript /** * A representation of a Touch Bar input. @@ -131,8 +130,7 @@ Popover be defined in the ``children`` property of the parent. Popovers can also be shown and hidden programmatically, by calling - .. highlight:: JavaScript - .. code:: + .. code:: JavaScript gTouchBarUpdater.showPopover( TouchBarHelper.baseWindow, @@ -160,8 +158,8 @@ Examples Some examples of ``gBuiltInInputs`` objects follow. A simple button - .. highlight:: JavaScript - .. code:: + + .. code:: JavaScript Back: { title: "back", @@ -176,8 +174,7 @@ A simple button The search popover This is the input that occupies the Touch Bar when the address bar is focused. - .. highlight:: JavaScript - .. code:: + .. code:: JavaScript SearchPopover: { title: "search-popover", diff --git a/browser/components/urlbar/docs/overview.rst b/browser/components/urlbar/docs/overview.rst index 0ff1ee5ad797..c0556ee485d1 100644 --- a/browser/components/urlbar/docs/overview.rst +++ b/browser/components/urlbar/docs/overview.rst @@ -22,8 +22,7 @@ The UrlbarQueryContext The *UrlbarQueryContext* object describes a single instance of a search. It is augmented as it progresses through the system, with various information: -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript UrlbarQueryContext { allowAutofill; // {boolean} If true, providers are allowed to return @@ -101,8 +100,7 @@ used by the user to restrict the search to specific result type (See the The tokenizer uses heuristics to determine each token's type, as such the consumer may want to check the value before applying filters. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript UrlbarProvidersManager { registerProvider(providerObj); @@ -135,8 +133,7 @@ implementation details may vary deeply among different providers. Internal providers can access the Places database through the *PlacesUtils.promiseLargeCacheDBConnection* utility. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript class UrlbarProvider { /** @@ -213,8 +210,7 @@ indicated by the UrlbarQueryContext.muxer property. The Muxer is a replaceable component, as such what is described here is a reference for the default View, but may not be valid for other implementations. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript class UrlbarMuxer { /** @@ -248,8 +244,7 @@ View (e.g. showing/hiding a panel). It is also responsible for reporting Telemet Each *View* has a different *Controller* instance. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript UrlbarController { async startQuery(queryContext); @@ -278,8 +273,7 @@ user and handling their input. Implements an input box *View*, owns an *UrlbarView*. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript UrlbarInput { constructor(options = { textbox, panel }); @@ -323,8 +317,7 @@ Implements an input box *View*, owns an *UrlbarView*. Represents the base *View* implementation, communicates with the *Controller*. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript UrlbarView { // Manage View visibility. @@ -359,7 +352,7 @@ properties, supported by all of the results. Result types are also enumerated by *UrlbarUtils.RESULT_TYPE*. -.. code-block:: +.. code-block:: JavaScript UrlbarResult { constructor(resultType, payload); @@ -384,8 +377,7 @@ properties, supported by all of the results. The following RESULT_TYPEs are supported: -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript // An open tab. // Payload: { icon, url, userContextId } diff --git a/browser/components/urlbar/docs/utilities.rst b/browser/components/urlbar/docs/utilities.rst index 8fa3b8509e7a..9e300878729b 100644 --- a/browser/components/urlbar/docs/utilities.rst +++ b/browser/components/urlbar/docs/utilities.rst @@ -9,8 +9,7 @@ Various modules provide shared utilities to the other components: Implements a Map-like storage or urlbar related preferences. The values are kept up-to-date. -.. highlight:: JavaScript -.. code:: +.. code:: JavaScript // Always use browser.urlbar. relative branch, except for the preferences in // PREF_OTHER_DEFAULTS. diff --git a/build/docs/chrome-registration.rst b/build/docs/chrome-registration.rst index 7e46d9ab0a3c..5c40f5ced776 100644 --- a/build/docs/chrome-registration.rst +++ b/build/docs/chrome-registration.rst @@ -65,7 +65,7 @@ takes the action identified by that line, otherwise the chrome registry ignores that line (and prints a warning message in the runtime error console). -.. code:: +.. code:: text locale packagename localename path/to/files skin packagename skinname path/to/files @@ -81,7 +81,7 @@ Manifest instructions comments ~~~~~~~~ -.. code:: +.. code:: text # this line is a comment - you can put here whatever you want @@ -152,7 +152,7 @@ locale A locale package is registered with the line: -.. code:: +.. code:: text locale packagename localename uri/to/files/ [flags] @@ -167,7 +167,7 @@ skin A skin package is registered with the line: -.. code:: +.. code:: text skin packagename skinname uri/to/files/ [flags] @@ -183,7 +183,7 @@ style Style overlays (custom CSS which will be applied to a chrome page) are registered with the following syntax: -.. code:: +.. code:: text style chrome://URI-to-style chrome://stylesheet-URI [flags] @@ -195,7 +195,7 @@ file provided by the application or XULRunner. In order to allow for this, the chrome registration manifest allows for "override" instructions: -.. code:: +.. code:: text override chrome://package/type/original-uri.whatever new-resolved-URI [flags] @@ -212,7 +212,7 @@ resource Aliases can be created using the ``resource`` instruction: -.. code:: +.. code:: text resource aliasname uri/to/files/ [flags] @@ -239,7 +239,7 @@ Extensions may install into multiple applications. There may be chrome registration lines which only apply to one particular application. The flag -.. code:: +.. code:: text application=app-ID @@ -264,7 +264,7 @@ Extensions may install into multiple versions of an application. There may be chrome registration lines which only apply to a particular application version. The flag -.. code:: +.. code:: text appversion=version appversion=10.5 diff --git a/build/docs/defining-xpcom-components.rst b/build/docs/defining-xpcom-components.rst index 51a1bb4fed85..891bad8ee2c6 100644 --- a/build/docs/defining-xpcom-components.rst +++ b/build/docs/defining-xpcom-components.rst @@ -229,7 +229,7 @@ file: ``Foo.h`` -.. code-block:: c++ +.. code-block:: cpp class Foo final : public nsISupports { public: @@ -238,7 +238,7 @@ file: ``Foo.cpp`` -.. code-block:: c++ +.. code-block:: cpp already_AddRefed Foo::GetSingleton() { // ... @@ -257,7 +257,7 @@ using a template specialization on an incomplete type: ``Foo.cpp`` -.. code-block:: c++ +.. code-block:: cpp NS_IMPL_COMPONENT_FACTORY(Foo) { return do_AddRef(new Foo()).downcast(); diff --git a/build/docs/locales.rst b/build/docs/locales.rst index 443eebb4e5b4..07b9728353dd 100644 --- a/build/docs/locales.rst +++ b/build/docs/locales.rst @@ -188,11 +188,11 @@ localization ecosystem at Mozilla, and `the documentation about the file format `_ explains how to set them up, and what the entries mean. In short, you find -.. code-block:: +.. code-block:: toml - [[paths]] - reference = browser/locales/en-US/** - l10n = {l}browser/** + [paths] + reference = browser/locales/en-US/** + l10n = {l}browser/** to add a directory for all localizations. Changes to these files are best submitted for review by :Pike or :flod. @@ -285,10 +285,10 @@ a ``key``, and an action. An example like .. code-block:: toml - [[filters]] - path = "{l}calendar/chrome/calendar/calendar-event-dialog.properties" - key = "re:.*Nounclass[1-9].*" - action = "ignore" + [filters] + path = "{l}calendar/chrome/calendar/calendar-event-dialog.properties" + key = "re:.*Nounclass[1-9].*" + action = "ignore" indicates that the matching messages in ``calendar-event-dialog.properties`` are optional. diff --git a/devtools/docs/user/browser_console/index.rst b/devtools/docs/user/browser_console/index.rst index a22a43feb28b..00679fbb0635 100644 --- a/devtools/docs/user/browser_console/index.rst +++ b/devtools/docs/user/browser_console/index.rst @@ -27,7 +27,7 @@ You can open the Browser Console in one of two ways: You can also start the Browser Console by launching Firefox from the command line and passing the ``-jsconsole`` argument: -.. code-block:: +.. code-block:: bash /Applications/FirefoxAurora.app/Contents/MacOS/firefox-bin -jsconsole diff --git a/devtools/docs/user/devtoolsapi/index.rst b/devtools/docs/user/devtoolsapi/index.rst index 19fce6ddd925..31a44a022f05 100644 --- a/devtools/docs/user/devtoolsapi/index.rst +++ b/devtools/docs/user/devtoolsapi/index.rst @@ -30,7 +30,7 @@ gDevTools The ``gDevTools`` API can be used to register new tools, themes and handle toolboxes for different tabs and windows. To use the ``gDevTools`` API from an add-on, it can be imported with following snippet -.. code-block:: +.. code-block:: JavaScript const { gDevTools } = require("resource:///modules/devtools/gDevTools.jsm"); @@ -501,7 +501,7 @@ Example Here's a minimal definition for a tool. -.. code-block:: javascript +.. code-block:: JavaScript let def = { id: "my-tool", @@ -561,7 +561,7 @@ Example Here's a basic template for a ToolPanel implementation. -.. code-block:: javascript +.. code-block:: JavaScript // In the ToolDefinition object, do // build: (window, target) => new MyPanel(window, target), @@ -642,7 +642,7 @@ Examples Here's a few examples using the ``gDevTools`` object. -.. code-block:: javascript +.. code-block:: JavaScript let onInit = (eventName, toolbox, netmonitor) => console.log("Netmonitor initialized!"); @@ -751,7 +751,7 @@ Examples Register a tool -.. code-block:: javascript +.. code-block:: JavaScript gDevTools.registerTool({ // FIXME: missing key related properties. @@ -775,7 +775,7 @@ Register a tool Open a tool, or select it if the toolbox is already open: -.. code-block:: javascript +.. code-block:: JavaScript let target = TargetFactory.forTab(gBrowser.selectedTab); let toolbox = gDevTools.openToolbox(target, null, "inspector"); @@ -788,7 +788,7 @@ Open a tool, or select it if the toolbox is already open: Add a sidebar to an existing tool: -.. code-block:: javascript +.. code-block:: JavaScript let sidebar = new ToolSidebar(xulTabbox, toolPanel, "toolId"); sidebar.addTab("tab1", "chrome://browser/content/.../tab1.xhtml", true); diff --git a/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst b/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst index 99cab0e28f3d..3a225fded9b7 100644 --- a/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst +++ b/docs/code-quality/coding-style/using_cxx_in_firefox_code.rst @@ -748,7 +748,7 @@ globals affect startup time! But sometimes we have to do ugly things.) Non-portable example: -.. code-block:: c++ +.. code-block:: cpp FooBarClass static_object(87, 92); @@ -766,7 +766,7 @@ probably long gone by now, but even with the feature working correctly, there are so many problems with correctly ordering C++ constructors that it's easier to just have an init function: -.. code-block:: c++ +.. code-block:: cpp static FooBarClass* static_object; @@ -840,7 +840,7 @@ Make header files compatible with C and C++ Non-portable example: -.. code-block:: c++ +.. code-block:: cpp /*oldCheader.h*/ int existingCfunction(char*); @@ -866,7 +866,7 @@ fine.) Portable example: -.. code-block:: c++ +.. code-block:: cpp /* oldCheader.h*/ PR_BEGIN_EXTERN_C @@ -906,7 +906,7 @@ constructor as private and not supply a definition. While you're at it, do the same for the assignment operator used for assignment of objects of the same class. Example: -.. code-block:: c++ +.. code-block:: cpp class Foo { ... @@ -936,7 +936,7 @@ Type scalar constants to avoid unexpected ambiguities Non-portable code: -.. code-block:: c++ +.. code-block:: cpp class FooClass { // having such similar signatures @@ -959,7 +959,7 @@ method calls. Portable code: -.. code-block:: c++ +.. code-block:: cpp class FooClass { // having such similar signatures @@ -1017,7 +1017,7 @@ favorite platform that you never use. Bad code example: -.. code-block:: c++ +.. code-block:: cpp #ifdef MOZ_ENABLE_JPEG_FOUR_BILLION #include // <--- don't do this @@ -1051,7 +1051,7 @@ Some compilers do not pack the bits when different bitfields are given different types. For example, the following struct might have a size of 8 bytes, even though it would fit in 1: -.. code-block:: c++ +.. code-block:: cpp struct { char ch: 1; diff --git a/docs/writing-rust-code/cpp-interop.md b/docs/writing-rust-code/cpp-interop.md index 0ffc155c47f2..9e9c5166838c 100644 --- a/docs/writing-rust-code/cpp-interop.md +++ b/docs/writing-rust-code/cpp-interop.md @@ -128,7 +128,7 @@ which will be placed in `$OBJDIR/dist/include/mozilla/intl/`. Finally, include the generated header into a C++ file and call the function. -```c++ +```cpp #include "mozilla/intl/unic_langid_ffi_generated.h" using namespace mozilla::intl::ffi; @@ -159,7 +159,7 @@ extern "C" { } ``` -```c++ +```cpp ffi::FluentPlatform FluentBuiltInGetPlatform() { return ffi::FluentPlatform::Linux; } @@ -201,7 +201,7 @@ pub unsafe extern "C" fn unic_langid_as_string( Next, in a C++ header define a destructor via `DefaultDelete`. -```c++ +```cpp #include "mozilla/intl/unic_langid_ffi_generated.h" #include "mozilla/UniquePtr.h" @@ -224,7 +224,7 @@ free the code, which might lead to strange behaviour!) Finally, implement the class. -```c++ +```cpp class Locale { public: explicit Locale(const nsACString& aLocale) diff --git a/dom/docs/scriptSecurity/index.rst b/dom/docs/scriptSecurity/index.rst index b3e0f92d1450..420f480d3c21 100644 --- a/dom/docs/scriptSecurity/index.rst +++ b/dom/docs/scriptSecurity/index.rst @@ -258,7 +258,7 @@ Expanded principal An expanded principal is specified as an array of origins: -.. code:: +.. code:: JavaScript ["http://mozilla.org", "http://moz.org"] diff --git a/intl/l10n/docs/crosschannel/content.rst b/intl/l10n/docs/crosschannel/content.rst index 01f5e1ab660d..1a1c8af87957 100644 --- a/intl/l10n/docs/crosschannel/content.rst +++ b/intl/l10n/docs/crosschannel/content.rst @@ -52,7 +52,7 @@ Created Content Structure The created content is laid out in the directory in the same structure as the files in ``l10n-central``. The localizable files end up like this: -.. code-block:: +.. code-block:: text browser/ browser/ diff --git a/intl/l10n/docs/fluent/tutorial.rst b/intl/l10n/docs/fluent/tutorial.rst index 7b523d64a684..a2f2d4c4fe44 100644 --- a/intl/l10n/docs/fluent/tutorial.rst +++ b/intl/l10n/docs/fluent/tutorial.rst @@ -2,7 +2,7 @@ :language: html .. role:: js(code) - :language: javascript + :language: JavaScript ============================= Fluent for Firefox Developers @@ -231,7 +231,7 @@ Fluent will overlay the translation onto the source fragment preserving attribut :code:`class` and :code:`href` from the source and adding translations for the elements inside. The resulting localized content will look like this: -.. code-block:: +.. code-block:: html

You are using Firefox Version: 60.0. @@ -284,7 +284,7 @@ localization context for this document and exposes it to runtime code as well. With a focus on `declarative localization`__, the primary method of localization is to alter the localization attributes in the DOM. Fluent provides a method to facilitate this: -.. code-block:: javascript +.. code-block:: JavaScript document.l10n.setAttributes(element, "new-panel-header"); @@ -293,7 +293,7 @@ animation frame. This API can be used to set both the ID and the arguments at the same time. -.. code-block:: javascript +.. code-block:: JavaScript document.l10n.setAttributes(element, "containers-disable-alert-ok-button", { tabCount: 5 @@ -302,7 +302,7 @@ This API can be used to set both the ID and the arguments at the same time. If only the arguments need to be updated, then it's possible to use the :code:`setArgs` method. -.. code-block:: javascript +.. code-block:: JavaScript document.l10n.setArgs(element, { tabCount: 5 @@ -321,7 +321,7 @@ Non-Markup Localization In rare cases, when the runtime code needs to retrieve the translation and not apply it onto the DOM, Fluent provides an API to retrieve it: -.. code-block:: javascript +.. code-block:: JavaScript let [ msg ] = await document.l10n.formatValues([ {id: "remove-containers-description"} @@ -351,7 +351,7 @@ developer or localizer. __ https://github.com/projectfluent/fluent/wiki/BiDi-in-Fluent -.. code-block:: javascript +.. code-block:: JavaScript document.l10n.setAttributes(element, "welcome-message", { userName: "اليسع", @@ -376,7 +376,7 @@ standard called `Plural Rules`_. In order to allow localizers to use it, all the developer has to do is to pass an external argument number: -.. code-block:: javascript +.. code-block:: JavaScript document.l10n.setAttributes(element, "unread-warning", { unreadCount: 5 }); @@ -442,7 +442,7 @@ but its default formatting will be pretty expressive. In most cases, the develop may want to use some of the :js:`Intl.DateTimeFormat` options to select the default representation of the date in string: -.. code-block:: javascript +.. code-block:: JavaScript document.l10n.formatValue("welcome-message", { startDate: FluentDateTime(new Date(), { @@ -518,7 +518,7 @@ In rare edge cases where the developer needs to fetch additional resources, or the same resources in another language, it is possible to create additional Localization object manually using the `Localization` class: -.. code-block:: javascript +.. code-block:: JavaScript const myL10n = new Localization([ "branding/brand.ftl", @@ -547,7 +547,7 @@ one by passing an `sync = false` argument to the constructor, or calling the `Se on the class. -.. code-block:: javascript +.. code-block:: JavaScript const myL10n = new Localization([ "branding/brand.ftl", @@ -584,7 +584,7 @@ In case of raw i18n the :js:`resolvedOptions` method on all :js:`Intl.*` formatt makes it relatively easy. In case of localization, the recommended way is to test that the code sets the right :code:`l10n-id`/:code:`l10n-args` attributes like this: -.. code-block:: javascript +.. code-block:: JavaScript testedFunction(); @@ -600,7 +600,7 @@ the code sets the right :code:`l10n-id`/:code:`l10n-args` attributes like this: If the code really has to test for particular values in the localized UI, it is always better to scan for a variable: -.. code-block:: javascript +.. code-block:: JavaScript testedFunction(); diff --git a/ipc/docs/ipdl.rst b/ipc/docs/ipdl.rst index 1491d2bdc490..de8271dee92e 100644 --- a/ipc/docs/ipdl.rst +++ b/ipc/docs/ipdl.rst @@ -245,7 +245,7 @@ Referencing Externally Defined Data Types: IPDL Includes Let's begin with ``PMyManager.ipdl``. It starts by including types that it will need from other places: -.. code-block:: c++ +.. code-block:: cpp include protocol PMyManaged; include MyTypes; // for MyActorPair @@ -286,7 +286,7 @@ Namespaces From the IPDL file: -.. code-block:: c++ +.. code-block:: cpp namespace mozilla { namespace myns { @@ -314,7 +314,7 @@ Generating IPDL-Aware C++ Data Types: IPDL Structs and Unions ``PMyManager.ipdl`` and ``MyTypes.ipdlh`` define: -.. code-block:: c++ +.. code-block:: cpp [Comparable] union MyUnion { float; @@ -349,7 +349,7 @@ The real point of any ``.ipdl`` file is that each defines exactly one actor protocol. The definition always matches the ``.ipdl`` filename. Repeating the one in ``PMyManager.ipdl``: -.. code-block:: c++ +.. code-block:: cpp sync protocol PMyManager { manages PMyManaged; @@ -412,7 +412,7 @@ protocol, it must also be the case that ``PMyManaged.ipdl`` includes ``PMyManager`` and declares that ``PMyManaged`` is ``managed`` by ``PMyManager``. Recalling the code: -.. code-block:: c++ +.. code-block:: cpp // PMyManaged.ipdl include protocol PMyManager; @@ -451,7 +451,7 @@ Declaring IPDL Messages The final part of the actor definition is the declaration of messages: -.. code-block:: c++ +.. code-block:: cpp sync protocol PMyManager { // ... @@ -767,7 +767,7 @@ binary data format for a type. Both options are available. We haven't seen any of this C++ yet. Let's look at the data types included from ``MyDataTypes.h``: -.. code-block:: c++ +.. code-block:: cpp // MyDataTypes.h namespace mozilla::myns { @@ -840,7 +840,7 @@ should only allocate a ``MyUnusedData`` to return if it so desires. These are straight-forward implementations of the ``ParamTraits`` methods for ``MyData``: -.. code-block:: c++ +.. code-block:: cpp /* static */ void IPC::ParamTraits::Write(MessageWriter* m, const paramType& in) { WriteParam(m, in.s); @@ -893,7 +893,7 @@ them. The generated ``ParamTraits`` confirm that the enum is in valid range; ``Read`` will return false otherwise. As an example, here is the ``MyActorEnum`` included from ``MyActorUtils.h``: -.. code-block:: c++ +.. code-block:: cpp enum MyActorEnum { e1, e2, e3, e4, e5 }; @@ -908,7 +908,7 @@ IPDL structs and unions become C++ classes that provide interfaces that are fairly self-explanatory. Recalling ``MyUnion`` and ``MyActorPair`` from `IPDL Structs and Unions`_ : -.. code-block:: c++ +.. code-block:: cpp union MyUnion { float; @@ -922,7 +922,7 @@ fairly self-explanatory. Recalling ``MyUnion`` and ``MyActorPair`` from These compile to: -.. code-block:: c++ +.. code-block:: cpp class MyUnion { enum Type { Tfloat, TMyOtherData }; @@ -985,7 +985,7 @@ that declare our actor implementation subclasses (``MyManagerParent.h`` and So ``MyManagerParent.h`` looks like this: -.. code-block:: c++ +.. code-block:: cpp #include "PMyManagerParent.h" @@ -1041,7 +1041,7 @@ returns a value: ``AnotherMsg``. This is done with ``SendAnotherMsg``, which is defined automatically by IPDL in the base class ``PMyManagerParent``. There are two signatures for ``Send`` and they look like this: -.. code-block:: c++ +.. code-block:: cpp // Return a Promise that IPDL will resolve with the response or reject. RefPtr> @@ -1074,7 +1074,7 @@ simpler form; they return a ``bool`` indicating success or failure and return response values in non-const parameters, as the ``Recv`` methods do. For example, ``PMyManagerChild`` defines this to send the sync message ``SomeMsg``: -.. code-block:: c++ +.. code-block:: cpp // generated in PMyManagerChild bool SendSomeMsg(const Maybe& aActors, const nsTArray& aMyData, @@ -1192,7 +1192,7 @@ beneficial to have it receive some final data. The relevant part of the parent class looks like this: -.. code-block:: c++ +.. code-block:: cpp class MyManagerParent : public PMyManagerParent { already_AddRefed AllocPMyManagedParent(); @@ -1218,7 +1218,7 @@ operational. The ``Send`` method for a constructor is similarly different from other ``Send`` methods. In the child actor, ours looks like this: -.. code-block:: c++ +.. code-block:: cpp IPCResult SendPMyManagedConstructor(PMyManagedChild* aActor); @@ -1244,7 +1244,7 @@ endpoint. cannot safely be a class instance method. Instead, unlike other ``Send`` methods, it's a ``static`` class method and takes the actor as a parameter: - .. code-block:: c++ + .. code-block:: cpp static IPCResult Send__delete__(PMyManagerChild* aToDelete); @@ -1358,7 +1358,7 @@ The most common way to create new top level actors is by creating a pair of connected Endpoints and sending one to the other actor. This is done exactly the way it sounds. For example: -.. code-block:: c++ +.. code-block:: cpp bool MyPreexistingActorParent::MakeMyActor() { Endpoint parentEnd; @@ -1395,7 +1395,7 @@ receiving them as well. ``MyPreexistingActorChild`` still has to receive the create message. The code for that handler is pretty similar: -.. code-block:: c++ +.. code-block:: cpp IPCResult MyPreexistingActorChild::RecvCreateMyActorChild(Endpoint&& childEnd) { RefPtr child = new MyActorChild; @@ -1519,7 +1519,7 @@ with normal managees but, instead of ``new``-ing the child actor and then passing it in a ``SendFooConstructor`` call, background actors issue the send call to the ``BackgroundChild`` manager, which returns the new child: -.. code-block:: c++ +.. code-block:: cpp // Bind our new PMyBackgroundActorChild to the current thread. PBackgroundChild* bc = BackgroundChild::GetOrCreateForCurrentThread(); diff --git a/ipc/docs/processes.rst b/ipc/docs/processes.rst index b9c3cb263d1d..89ec5e80131c 100644 --- a/ipc/docs/processes.rst +++ b/ipc/docs/processes.rst @@ -561,7 +561,7 @@ Creating the New Process The sample does this in ``DemoParent::LaunchDemoProcess``. The core behavior is fairly clear: -.. code-block:: c++ +.. code-block:: cpp /* static */ bool DemoParent::LaunchDemoProcess( @@ -612,7 +612,7 @@ by IPDL, which is why it doesn't get assigned to anything. This simplifies the design dramatically. IPDL takes ownership when the actor calls ``Bind`` from the ``Init`` method: -.. code-block:: c++ +.. code-block:: cpp DemoParent::DemoParent(UniqueHost&& aHost) : mHost(std::move(aHost)) {} @@ -648,7 +648,7 @@ main thread will run (this is discussed later) and we need to create our ``ProcessChild`` subclass. This is not an insignificant choice so pay close attention to the `MessageLoop` options: -.. code-block:: c++ +.. code-block:: cpp MessageLoop::Type uiLoopType; switch (XRE_GetProcessType()) { @@ -679,7 +679,7 @@ to be overridden to parse them. It does this, binds our actor by calling ``Bind`` as was done with the parent, then initializes a bunch of components that the process expects to use: -.. code-block:: c++ +.. code-block:: cpp bool DemoChild::Init(int aArgc, char* aArgv[]) { #if defined(MOZ_SANDBOX) && defined(XP_WIN) @@ -759,7 +759,7 @@ normal top-level actor (or any managed actor after calling when some (as yet unwritten) **Demo** process code calls ``DemoChild::Shutdown``. -.. code-block:: c++ +.. code-block:: cpp /* static */ void DemoChild::Shutdown() { @@ -803,7 +803,7 @@ The comment in the code makes two important points: We can also see that, once the ``EmptyMessageQueue`` response is run, we are releasing ``gDemoChild``, which will result in the termination of the process. -.. code-block:: c++ +.. code-block:: cpp DemoChild::~DemoChild() { // ... @@ -814,7 +814,7 @@ At this point, the ``DemoParent`` in the main process is alerted to the channel closure because IPDL will call its :ref:`ActorDestroy ` method. -.. code-block:: c++ +.. code-block:: cpp void DemoParent::ActorDestroy(ActorDestroyReason aWhy) { if (aWhy == AbnormalShutdown) { @@ -841,7 +841,7 @@ responsible for our intended behavior, not just bootstrapping the new process. Above, we saw that this is started by ``Host::MakeBridgeAndResolve`` after the ``DemoParent`` connection is established. -.. code-block:: c++ +.. code-block:: cpp bool DemoParent::Host::MakeBridgeAndResolve() { ipc::Endpoint parent; @@ -871,7 +871,7 @@ actors, then we send the child one to the new process and resolve a promise with the other. The **Demo** process creates its ``PDemoHelplineChild`` easily: -.. code-block:: c++ +.. code-block:: cpp mozilla::ipc::IPCResult DemoChild::RecvCreateDemoHelplineChild( Endpoint&& aEndpoint) { @@ -884,7 +884,7 @@ easily: ``MakeProcessAndGetAssistance`` binds the same way: -.. code-block:: c++ +.. code-block:: cpp RefPtr demoHelplineParent = new DemoHelplineParent(); if (!endpoint.Bind(demoHelplineParent)) { @@ -914,7 +914,7 @@ process, we simply write an async ``PContent`` message that calls ``DemoParent::LaunchDemoProcess`` and use the message handler's promise as our promise: -.. code-block:: c++ +.. code-block:: cpp /* static */ bool DemoHelplineParent::MakeProcessAndGetAssistance( @@ -990,7 +990,7 @@ We have covered the main parts needed for the sample. Now we just need to wire it all up. First, we add the new JS command to ``Navigator.webidl`` and ``Navigator.h``/``Navigator.cpp``: -.. code-block:: c++ +.. code-block:: cpp partial interface Navigator { [Throws] @@ -1020,7 +1020,7 @@ Then, we need to add the part that gets the string we use to resolve the promise in ``MakeProcessAndGetAssistance`` (or reject it if it hasn't been resolved by the time ``ActorDestroy`` is called): -.. code-block:: c++ +.. code-block:: cpp using DemoPromise = MozPromise; @@ -1064,7 +1064,7 @@ that the string was received. During closing, the actor's ``ActorDestroy`` method then calls the ``DemoChild::Shutdown`` method we defined in `Destroying the New Process`_: -.. code-block:: c++ +.. code-block:: cpp mozilla::ipc::IPCResult DemoHelplineChild::RecvRequestAssistance() { RefPtr me = this; @@ -1124,7 +1124,7 @@ because it is likely to be intermittent and may manifest more easily on some platforms/architectures than others. To create this bug, replace the ``SendEmptyMessageQueue`` call in ``DemoChild::Shutdown``: -.. code-block:: c++ +.. code-block:: cpp auto dc = gDemoChild; RefPtr runnable = NS_NewRunnableFunction( @@ -1138,7 +1138,7 @@ platforms/architectures than others. To create this bug, replace the with just an (asynchronous) call to ``Close``: -.. code-block:: c++ +.. code-block:: cpp NS_DispatchToMainThread(NS_NewRunnableFunction( "DemoChild::FinishShutdown", diff --git a/js/src/doc/build.rst b/js/src/doc/build.rst index 7e6a2eb0c2f0..7237c80dff2d 100644 --- a/js/src/doc/build.rst +++ b/js/src/doc/build.rst @@ -35,7 +35,7 @@ have. A basic ``MOZCONFIG`` file for doing a debug build, put into ``$HOME/mozconfigs/debug`` looks like this -.. code:: +.. code:: text # Build only the JS shell ac_add_options --enable-project=js @@ -53,7 +53,7 @@ A basic ``MOZCONFIG`` file for doing a debug build, put into ``$HOME/mozconfigs/ To activate a particular ``MOZCONFIG``, set the environment variable: -.. code:: +.. code:: text export MOZCONFIG=$HOME/mozconfigs/debug @@ -64,7 +64,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:: +.. code:: console $ cd $ ./mach build @@ -98,7 +98,7 @@ Testing Once built, you can then use ``mach`` to run the ``jit-tests``: -.. code:: +.. code:: console $ ./mach jit-test @@ -106,7 +106,7 @@ Similarly you can use also run ``jstests``. These include a local, intermittently updated, copy of all `test262 `_ tests. -.. code:: +.. code:: console $ ./mach jstests @@ -119,7 +119,7 @@ To switch to an optimized build, such as for performance testing, one need only have an optimized build ``MOZCONFIG``, and then activate it. An example ``$HOME/mozconfigs/optimized`` ``MOZCONFIG`` looks like this: -.. code:: +.. code:: text # Build only the JS shell ac_add_options --enable-project=js @@ -148,7 +148,7 @@ Building SpiderMonkey on Android your `PATH` environment. You can do this by running the following line in a shell, or adding it to a shell profile init file: -.. code:: +.. code:: console $ export PATH="$PATH:~/.mozbuild/android-sdk-linux/platform-tools" @@ -156,9 +156,9 @@ Building SpiderMonkey on Android the :ref:`Setting up a MOZCONFIG` documentation, and include the following line: -.. code:: +.. code:: console - ac_add_options --target=aarch64-linux-android + $ ac_add_options --target=aarch64-linux-android - Then compile as usual with `mach build` with this `MOZCONFIG` file. @@ -169,9 +169,9 @@ Running jit-tests on Android as described above, or make sure it is on the same subnetwork as the host. It should appear in the list of devices seen by `adb`: -.. code:: +.. code:: console - adb devices + $ adb devices This command should show you a device ID with the name of the device. If it doesn't, make sure that you have enabled Developer options on your device, as @@ -192,9 +192,9 @@ the host machine. - Upload the `gdbserver` precompiled binary from the NDK from the host machine to the Android device, using this command on the host: -.. code:: +.. code:: console - adb push \ + $ adb push \ ~/.mozbuild/android-ndk-r23c/prebuilt/android-arm64/gdbserver/gdbserver \ /data/local/tmp/test_root/bin @@ -205,16 +205,16 @@ the host machine. so we can connect to a local port from the host, without needing to find what the IP address of the Android device is: -.. code:: +.. code:: console - adb forward tcp:5039 tcp:5039 + $ adb forward tcp:5039 tcp:5039 - Start `gdbserver` on the phone, passing the JS shell command line arguments to gdbserver: -.. code:: +.. code:: console - adb shell export LD_LIBRARY_PATH=/data/local/tmp/test_root/bin '&&' /data/local/tmp/test_root/bin/gdbserver :5039 /data/local/tmp/test_root/bin/js /path/to/test.js + $ adb shell export LD_LIBRARY_PATH=/data/local/tmp/test_root/bin '&&' /data/local/tmp/test_root/bin/gdbserver :5039 /data/local/tmp/test_root/bin/js /path/to/test.js .. note:: @@ -234,14 +234,14 @@ the host machine. - On the host, start the precompiled NDK version of GDB that matches your host architecture, passing it the path to the shell compiled with `mach` above: -.. code:: +.. code:: console - ~/.mozbuild/android-ndk-r23c/prebuilt/linux-x86_64/bin/gdb /path/to/objdir-aarch64-linux-android/dist/bin/js + $ ~/.mozbuild/android-ndk-r23c/prebuilt/linux-x86_64/bin/gdb /path/to/objdir-aarch64-linux-android/dist/bin/js - Then connect remotely to the GDB server that's listening on the Android device: -.. code:: +.. code:: console - (gdb) target remote :5039 - (gdb) continue + $(gdb) target remote :5039 + $(gdb) continue diff --git a/js/src/doc/test.rst b/js/src/doc/test.rst index 6c2e8de4d61d..32d7a2abf2fd 100644 --- a/js/src/doc/test.rst +++ b/js/src/doc/test.rst @@ -14,7 +14,7 @@ Running Test262 locally The jstests shell harness is in ``js/src/tests/jstests.py``. It can be invoked using -.. code:: +.. code:: bash ./mach jstests @@ -22,7 +22,7 @@ Note that mach will generally find the JS shell itself; the --shell argument can Test262 includes a lot of tests. When working on a specific feature, it is often useful to specify a subset of tests: -.. code:: +.. code:: bash ./mach jstests TEST_PATH_SUBSTRING [TEST_PATH_SUBSTRING_2 ...] @@ -35,13 +35,13 @@ This runs all tests whose paths contain any TEST_PATH_SUBSTRING. To exclude test For a complete list of options, use: -.. code:: +.. code:: bash ./mach jstests -- -h The Test262 tests can also be run in the browser, using: -.. code:: +.. code:: bash ./mach jstestbrowser @@ -54,13 +54,13 @@ Running jit-tests locally The jit-test shell harness is in ``js/src/jit-test/jit_test.py``. It can be invoked using -.. code:: +.. code:: bash ./mach jit-test Basic usage of ``mach jit-test`` is similar to ``mach jstests``. A subset of tests can be specified: -.. code:: +.. code:: bash ./mach jit-test TEST_PATH_SUBSTRING [TEST_PATH_SUBSTRING_2 ...] diff --git a/mobile/android/docs/geckoview/consumer/web-extensions.rst b/mobile/android/docs/geckoview/consumer/web-extensions.rst index 24c0d04e0d44..ef4e75348f6e 100644 --- a/mobile/android/docs/geckoview/consumer/web-extensions.rst +++ b/mobile/android/docs/geckoview/consumer/web-extensions.rst @@ -123,7 +123,7 @@ Note: extension can only send messages from content scripts if explicitly authorized by the app by adding ``nativeMessagingFromContent`` in the manifest.json file, e.g. -.. code:: +.. code:: json "permissions": [ "nativeMessaging", @@ -219,7 +219,7 @@ found on the page. Note that our ``nativeApp`` identifier used for /assets/messaging/messaging.js ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -.. code:: javascript +.. code:: JavaScript let manifest = document.querySelector("head > link[rel=manifest]"); if (manifest) { @@ -301,7 +301,7 @@ For this example, the extension side will do the following: /assets/messaging/background.js ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.. code:: javascript +.. code:: JavaScript // Establish connection with app let port = browser.runtime.connectNative("browser"); diff --git a/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst b/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst index e4235dd4dd7e..7ef34e11d5d6 100644 --- a/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst +++ b/mobile/android/docs/geckoview/contributor/geckoview-architecture.rst @@ -392,7 +392,7 @@ be declared in GeckoView's ``AndroidManifest.xml``. For example, this is the definition of the ``media`` process: -.. code-block:: +.. code-block:: xml .cpp: @@ -200,7 +200,7 @@ track allocations correctly Gecko must be built with ``jemalloc`` disabled. Additionally, the native memory profiler appears to only work with ``aarch64`` builds. The following must therefore be present in your ``mozconfig`` file: -.. code:: +.. code:: text ac_add_options --target=aarch64 ac_add_options --disable-jemalloc @@ -212,7 +212,7 @@ found, therefore in order for the profile to be symbolicated you must prevent symbols being stripped during the build process. To do so, add the following to your ``mozconfig``: -.. code:: +.. code:: text ac_add_options STRIP_FLAGS=--strip-debug diff --git a/netwerk/docs/cache2/doc.rst b/netwerk/docs/cache2/doc.rst index 71982be9e634..b9be70abc882 100644 --- a/netwerk/docs/cache2/doc.rst +++ b/netwerk/docs/cache2/doc.rst @@ -338,7 +338,7 @@ arguments of :ref:`nsILoadContextInfo `. The form is followi pending in `bug 968593 `__): -.. code:: +.. code:: JavaScript a,b,i1009,p, diff --git a/netwerk/docs/http_server_for_testing.rst b/netwerk/docs/http_server_for_testing.rst index 4222846f0be9..e4d0290c1eb2 100644 --- a/netwerk/docs/http_server_for_testing.rst +++ b/netwerk/docs/http_server_for_testing.rst @@ -69,13 +69,13 @@ Running the server From test suites, the server should be importable as a testing-only JS module: -.. code:: javascript +.. code:: JavaScript ChromeUtils.import("resource://testing-common/httpd.js"); Once you've done that, you can create a new server as follows: -.. code:: javascript +.. code:: JavaScript let server = new HttpServer(); // Or nsHttpServer() if you don't use ChromeUtils.import. @@ -128,7 +128,7 @@ handlers) it serves. To modify the headers for a file, create a sibling file with the first file's name followed by ``^headers^``. Here's an example of how such a file might look: -.. code:: +.. code:: text HTTP 404 I want a cool HTTP description! Content-Type: text/plain @@ -164,7 +164,7 @@ will generate. That function acts exactly like the ``handle`` function on the ``nsIHttpRequestHandler`` interface. First, tell the server what extension you're using: -.. code:: javascript +.. code:: JavaScript const SJS_EXTENSION = "cgi"; server.registerContentType(SJS_EXTENSION, "sjs"); @@ -172,7 +172,7 @@ extension you're using: Now just create an SJS with the extension ``cgi`` and write whatever you want. For example: -.. code:: javascript +.. code:: JavaScript function handleRequest(request, response) { @@ -201,7 +201,7 @@ every time processing occurs. To support stateful SJS behavior, the following functions have been added to the global scope in which a SJS handler executes, providing a simple key-value state storage mechanism: -.. code:: +.. code:: JavaScript /* * v : T means v is of type T @@ -247,7 +247,7 @@ request handler needs to store information from a first request of it for use in processing a second request of it — say, for example, if you wanted to implement a request handler implementing a counter: -.. code:: javascript +.. code:: JavaScript /** * Generates a response whose body is "0", "1", "2", and so on. each time a @@ -323,7 +323,7 @@ when a particular event occurs. single string argument and returns the object or ``null`` directly. In SJS, however, the process to return the value is slightly different: -.. code:: javascript +.. code:: JavaScript function handleRequest(request, response) { @@ -366,7 +366,7 @@ that the response will be written and finished by the handler. Here's an example of an SJS file which writes some data, waits five seconds, and then writes some more data and finishes the response: -.. code:: javascript +.. code:: JavaScript var timer = null; @@ -423,7 +423,7 @@ through httpd.js would throw an exception) and which has a header that spans multiple lines (httpd.js responses otherwise generate only single-line headers): -.. code:: javascript +.. code:: JavaScript function handleRequest(request, response) { diff --git a/other-licenses/snappy/src/README.md b/other-licenses/snappy/src/README.md index 7917d1bf05c7..8fd7dc09eddb 100644 --- a/other-licenses/snappy/src/README.md +++ b/other-licenses/snappy/src/README.md @@ -90,13 +90,13 @@ your calling file, and link against the compiled library. There are many ways to call Snappy, but the simplest possible is -```c++ +```cpp snappy::Compress(input.data(), input.size(), &output); ``` and similarly -```c++ +```cpp snappy::Uncompress(input.data(), input.size(), &output); ``` diff --git a/python/docs/index.rst b/python/docs/index.rst index 68b16ab649e9..0c97270bbcae 100644 --- a/python/docs/index.rst +++ b/python/docs/index.rst @@ -47,7 +47,7 @@ There's two ways of using 3rd-party Python dependencies: To add a ``pip install``-d package dependency, add it to your site's ``python/sites/.txt`` manifest file: -.. code:: +.. code:: text ... pypi:new-package== @@ -74,7 +74,7 @@ Next, add that package and any new transitive dependencies (you'll see them adde ``third_party/python/requirements.txt``) to the associated site's dependency manifest in ``python/sites/.txt``: -.. code:: +.. code:: text ... vendored:third_party/python/new-package diff --git a/python/mach/docs/windows-usage-outside-mozillabuild.rst b/python/mach/docs/windows-usage-outside-mozillabuild.rst index 6a034fd38449..f56cc2bf5cde 100644 --- a/python/mach/docs/windows-usage-outside-mozillabuild.rst +++ b/python/mach/docs/windows-usage-outside-mozillabuild.rst @@ -96,7 +96,7 @@ If you're using Git with Cinnabar, follow its `setup instructions \mach.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170. diff --git a/testing/marionette/client/docs/basics.rst b/testing/marionette/client/docs/basics.rst index ffb8c3716bc4..76ae71015bb6 100644 --- a/testing/marionette/client/docs/basics.rst +++ b/testing/marionette/client/docs/basics.rst @@ -24,8 +24,9 @@ Getting the Client The Python client is officially supported. To install it, first make sure you have `pip installed`_ then run: -.. parsed-literal:: - pip install marionette_driver +.. code-block:: bash + + $ pip install marionette_driver It's highly recommended to use virtualenv_ when installing Marionette to avoid package conflicts and other general nastiness. @@ -53,7 +54,8 @@ A session is a single instance of a Marionette client connected to a Marionette server. Before you can start executing commands, you need to start a session with :func:`start_session() `: -.. parsed-literal:: +.. code-block:: python + from marionette_driver.marionette import Marionette client = Marionette('127.0.0.1', port=2828) @@ -77,7 +79,8 @@ appropriate context. Use :func:`~Marionette.switch_to_window` to execute commands in the context of a new window: -.. parsed-literal:: +.. code-block:: python + original_window = client.current_window_handle for handle in client.window_handles: if handle != original_window: @@ -88,7 +91,8 @@ new window: Similarly, use :func:`~Marionette.switch_to_frame` to execute commands in the context of a new frame (e.g an