Magic-Mirror/gecko-dev
1
0
Fork 0
mirror of https://github.com/mozilla/gecko-dev.git synced 2024-11-23 12:51:06 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Bug 1840493 - doc/rst: fix some languages declaration r=firefox-source-docs-reviewers,webdriver-reviewers,necko-reviewers,geckoview-reviewers,devtools-reviewers,profiler-reviewers,championshuttler,whimboo,nchevobbe,julienw,amejiamarmol

Browse Source 
Differential Revision: https://phabricator.services.mozilla.com/D196268
This commit is contained in:
ogiorgis 2023-12-13 18:32:20 +00:00
parent 9666a364e6
commit 111705f5fd
41 changed files with 279 additions and 281 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
browser/components/touchbar/docs/index.rst
View File

@ -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",

26
browser/components/urlbar/docs/overview.rst
View File

@ -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 }

3
browser/components/urlbar/docs/utilities.rst
View File

@ -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.

24
build/docs/chrome-registration.rst
View File

@ -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<version
@ -287,7 +287,7 @@ This is particularly true for binary components. If there are chrome
registration lines which only apply to a particular Gecko version, the
flag
.. code::
.. code:: text
platformversion=version
platformversion<version
@ -333,7 +333,7 @@ Extensions (or themes) may offer different features depending on the
operating system on which Firefox is running. The value is compared to
the value of `OS_TARGET` for the platform.
.. code::
.. code:: text
os=WINNT
os=Darwin
@ -345,7 +345,7 @@ An extension or theme may need to operate differently depending on which
version of an operating system is running. For example, a theme may wish
to adopt a different look on Mac OS X 10.5 than 10.4:
.. code::
.. code:: text
osversion>=10.5

6
build/docs/defining-xpcom-components.rst
View File

@ -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> 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<nsISupports>();

16
build/docs/locales.rst
View File

@ -188,11 +188,11 @@ localization ecosystem at Mozilla, and `the documentation about the
file format <http://moz-l10n-config.readthedocs.io/en/latest/fileformat.html>`_
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.

2
devtools/docs/user/browser_console/index.rst
View File

@ -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

14
devtools/docs/user/devtoolsapi/index.rst
View File

@ -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);

18
docs/code-quality/coding-style/using_cxx_in_firefox_code.rst
View File

@ -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 <stdlib.h> // <--- 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;

8
docs/writing-rust-code/cpp-interop.md
View File

@ -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)

2
dom/docs/scriptSecurity/index.rst
View File

@ -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"]

2
intl/l10n/docs/crosschannel/content.rst
View File

@ -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/

26
intl/l10n/docs/fluent/tutorial.rst
View File

@ -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
<p data-l10n-id="update-application-info" data-l10n-args='{"version": "60.0"}'">
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();

40
ipc/docs/ipdl.rst
View File

@ -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<MyData>::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<MozPromise<MyOtherData, ResponseRejectReason, true>>
@ -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<MyActorPair>& aActors, const nsTArray<MyData>& 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<PMyManagedParent> 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<PMyActorParent> 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<PMyActorChild>&& childEnd) {
RefPtr<MyActorChild> 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();

32
ipc/docs/processes.rst
View File

@ -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 <Actor Lifetimes
in C++>` 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<PDemoHelplineParent> 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<PDemoHelplineChild>&& aEndpoint) {
@ -884,7 +884,7 @@ easily:
``MakeProcessAndGetAssistance`` binds the same way:
.. code-block:: c++
.. code-block:: cpp
RefPtr<DemoHelplineParent> 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<nsString, nsresult, true>;
@ -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<DemoHelplineChild> 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<nsIRunnable> 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",

44
js/src/doc/build.rst
View File

@ -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 <path to mozilla-central>
$ ./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 <https://github.com/tc39/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

12
js/src/doc/test.rst
View File

@ -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 ...]

6
mobile/android/docs/geckoview/consumer/web-extensions.rst
View File

@ -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");

2
mobile/android/docs/geckoview/contributor/geckoview-architecture.rst
View File

@ -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
<service
android:name="org.mozilla.gecko.media.MediaManager"

10
mobile/android/docs/geckoview/contributor/native-debugging.rst
View File

@ -25,7 +25,7 @@ Perform a debug build of Gecko.
1. Edit your ``mozconfig`` file and add the following lines. These will
ensure that the build includes debug checks and symbols.
.. code::
.. code:: text
ac_add_options --enable-debug
@ -33,7 +33,7 @@ Perform a debug build of Gecko.
``mozconfig`` if present. ``./mach configure`` will not allow
artifact builds to be enabled when generating a debug build.
.. code::
.. code:: text
# ac_add_options --enable-artifact-builds
@ -113,7 +113,7 @@ Debug Native code in Android Studio
debug window, and then select the ``lldb`` console tab. Type the
following into the console:
.. code::
.. code:: text
b <file>.cpp:<line number>
@ -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

2
netwerk/docs/cache2/doc.rst
View File

@ -338,7 +338,7 @@ arguments of :ref:`nsILoadContextInfo <nsILoadContextInfo>`. The form is followi
pending in `bug
968593 <https://bugzilla.mozilla.org/show_bug.cgi?id=968593>`__):
.. code::
.. code:: JavaScript
a,b,i1009,p,

20
netwerk/docs/http_server_for_testing.rst
View File

@ -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)
{

4
other-licenses/snappy/src/README.md
View File

@ -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);
```

4
python/docs/index.rst
View File

@ -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/<site>.txt`` manifest file:
.. code::
.. code:: text
...
pypi:new-package==<version>
@ -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/<site>.txt``:
.. code::
.. code:: text
...
vendored:third_party/python/new-package

2
python/mach/docs/windows-usage-outside-mozillabuild.rst
View File

@ -96,7 +96,7 @@ If you're using Git with Cinnabar, follow its `setup instructions <https://githu
If you're using Powershell, Windows will raise an error by default when you try to invoke
``.\mach.ps1``:
.. code::
.. code:: text
.\mach : File <topsrcdir>\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.

34
testing/marionette/client/docs/basics.rst
View File

@ -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() <Marionette.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 <iframe> element):
.. parsed-literal::
.. code-block:: python
iframe = client.find_element(By.TAG_NAME, 'iframe')
client.switch_to_frame(iframe)
@ -97,12 +101,13 @@ privileged scope where you can access things like the Firefox UI itself.
Content scope is where things like webpages live. You can switch between
`chrome` and `content` using the :func:`~Marionette.set_context` and :func:`~Marionette.using_context` functions:
.. parsed-literal::
.. code-block:: python
client.set_context(client.CONTEXT_CONTENT)
# content scope
with client.using_context(client.CONTEXT_CHROME):
#chrome scope
... do stuff ...
pass # ... do stuff ...
# content scope restored
@ -114,7 +119,8 @@ move through the back/forward cache using :func:`~Marionette.go_forward` and
:func:`~Marionette.go_back` respectively. To retrieve the currently
open website, use :func:`~Marionette.get_url`:
.. parsed-literal::
.. code-block:: python
url = 'http://mozilla.org'
client.navigate(url)
client.go_back()
@ -129,7 +135,8 @@ In order to inspect or manipulate actual DOM elements, they must first be found
using the :func:`~Marionette.find_element` or :func:`~Marionette.find_elements`
methods:
.. parsed-literal::
.. code-block:: python
from marionette_driver.marionette import WebElement
element = client.find_element(By.ID, 'my-id')
assert type(element) == WebElement
@ -140,7 +147,8 @@ For a full list of valid search strategies, see :doc:`advanced/findelement`.
Now that an element has been found, it's possible to manipulate it:
.. parsed-literal::
.. code-block:: python
element.click()
element.send_keys('hello!')
print(element.get_attribute('style'))
@ -162,7 +170,8 @@ functions. They accomplish what their names suggest, the former executes some
synchronous JavaScript, while the latter provides a callback mechanism for
running asynchronous JavaScript:
.. parsed-literal::
.. code-block:: python
result = client.execute_script("return arguments[0] + arguments[1];",
script_args=[2, 3])
assert result == 5
@ -170,7 +179,8 @@ running asynchronous JavaScript:
The async method works the same way, except it won't return until the
`resolve()` function is called:
.. parsed-literal::
.. code-block:: python
result = client.execute_async_script("""
let [resolve] = arguments;
setTimeout(function() {

14
third_party/function2/Readme.md vendored
View File

@ -63,7 +63,7 @@ Use `fu2::function` as a wrapper for copyable function wrappers and `fu2::unique
The standard implementation `std::function` and `fu2::function` are convertible to each other, see [the chapter convertibility of functions](#convertibility-of-functions) for details.
A function wrapper is declared as following:
```c++
```cpp
fu2::function<void(int, float) const>
// Return type ~^ ^ ^ ^
// Parameters ~~~~~|~~~~~| ^
@ -98,7 +98,7 @@ fu2::function<void(int, float) const>
`fu2::function` and `fu2::unique_function` (non copyable) are easy to use:
```c++
```cpp
fu2::function<void() const> fun = [] {
// ...
};
@ -111,7 +111,7 @@ fun();
`fu2::unique_function` also works with non copyable functors/ lambdas.
```c++
```cpp
fu2::unique_function<bool() const> fun = [ptr = std::make_unique<bool>(true)] {
return *ptr;
};
@ -127,7 +127,7 @@ otherfun();
A `fu2::function_view` can be used to create a non owning view on a persistent object. Note that the view is only valid as long as the object lives.
```c++
```cpp
auto callable = [ptr = std::make_unique<bool>(true)] {
return *ptr;
};
@ -164,7 +164,7 @@ fu2::function_view<bool() const> view(callable);
| fu2::unique_function | No | Yes | No |
| std::function | Yes | Yes | Yes |
```c++
```cpp
fu2::function<void()> fun = []{};
// OK
std::function<void()> std_fun = fun;
@ -197,14 +197,14 @@ struct my_capacity {
The following code defines an owning function with a variadic signature which is copyable and sfo optimization is disabled:
```c++
```cpp
template<typename Signature>
using my_function = fu2::function_base<true, true, fu2::capacity_none, true, false, Signature>;
```
The following code defines a non copyable function which just takes 1 argument, and has a huge capacity for internal sfo optimization. Also it must be called as r-value.
```c++
```cpp
template<typename Arg>
using my_consumer = fu2::function_base<true, false, fu2::capacity_fixed<100U>,
true, false, void(Arg)&&>;

28
third_party/picosha2/README.md vendored
View File

@ -13,7 +13,7 @@ PicoSHA2 is a tiny SHA256 hash generator for C++ with following properties:
## Generating SHA256 hash and hash hex string
```c++
```cpp
// any STL sequantial container (vector, list, dequeue...)
std::string src_str = "The quick brown fox jumps over the lazy dog";
@ -25,7 +25,7 @@ std::string hex_str = picosha2::bytes_to_hex_string(hash.begin(), hash.end());
## Generating SHA256 hash and hash hex string from byte stream
```c++
```cpp
picosha2::hash256_one_by_one hasher;
...
hasher.process(block.begin(), block.end());
@ -42,7 +42,7 @@ The file `example/interactive_hasher.cpp` has more detailed information.
## Generating SHA256 hash from a binary file
```c++
```cpp
std::ifstream f("file.txt", std::ios::binary);
std::vector<unsigned char> s(picosha2::k_digest_size);
picosha2::hash256(f, s.begin(), s.end());
@ -52,7 +52,7 @@ This `hash256` may use less memory than reading whole of the file.
## Generating SHA256 hash hex string from std::string
```c++
```cpp
std::string src_str = "The quick brown fox jumps over the lazy dog";
std::string hash_hex_str;
picosha2::hash256_hex_string(src_str, hash_hex_str);
@ -60,14 +60,14 @@ std::cout << hash_hex_str << std::endl;
//this output is "d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592"
```
```c++
```cpp
std::string src_str = "The quick brown fox jumps over the lazy dog";
std::string hash_hex_str = picosha2::hash256_hex_string(src_str);
std::cout << hash_hex_str << std::endl;
//this output is "d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592"
```
```c++
```cpp
std::string src_str = "The quick brown fox jumps over the lazy dog.";//add '.'
std::string hash_hex_str = picosha2::hash256_hex_string(src_str.begin(), src_str.end());
std::cout << hash_hex_str << std::endl;
@ -76,24 +76,24 @@ std::cout << hash_hex_str << std::endl;
## Generating SHA256 hash hex string from byte sequence
```c++
```cpp
std::vector<unsigned char> src_vect(...);
std::string hash_hex_str;
picosha2::hash256_hex_string(src_vect, hash_hex_str);
```
```c++
```cpp
std::vector<unsigned char> src_vect(...);
std::string hash_hex_str = picosha2::hash256_hex_string(src_vect);
```
```c++
```cpp
unsigned char src_c_array[picosha2::k_digest_size] = {...};
std::string hash_hex_str;
picosha2::hash256_hex_string(src_c_array, src_c_array+picosha2::k_digest_size, hash_hex_str);
```
```c++
```cpp
unsigned char src_c_array[picosha2::k_digest_size] = {...};
std::string hash_hex_str = picosha2::hash256_hex_string(src_c_array, src_c_array+picosha2::k_digest_size);
```
@ -101,7 +101,7 @@ std::string hash_hex_str = picosha2::hash256_hex_string(src_c_array, src_c_array
## Generating SHA256 hash byte sequence from STL sequential container
```c++
```cpp
//any STL sequantial container (vector, list, dequeue...)
std::string src_str = "The quick brown fox jumps over the lazy dog";
@ -112,7 +112,7 @@ std::vector<unsigned char> hash(picosha2::k_digest_size);
picosha2::hash256(src_str, hash);
```
```c++
```cpp
//any STL sequantial container (vector, list, dequeue...)
std::string src_str = "The quick brown fox jumps over the lazy dog";
@ -123,14 +123,14 @@ std::vector<unsigned char> hash(picosha2::k_digest_size);
picosha2::hash256(src_str.begin(), src_str.end(), hash);
```
```c++
```cpp
std::string src_str = "The quick brown fox jumps over the lazy dog";
unsigned char hash_byte_c_array[picosha2::k_digest_size];
// in: container, out: iterator(pointer) pair
picosha2::hash256(src_str, hash_byte_c_array, hash_byte_c_array+picosha2::k_digest_size);
```
```c++
```cpp
std::string src_str = "The quick brown fox jumps over the lazy dog";
std::vector<unsigned char> hash(picosha2::k_digest_size);
// in: iterator pair, out: iterator pair

4
toolkit/components/extensions/docs/generate_webidl_from_jsonschema.rst
View File

@ -21,7 +21,7 @@ Example: how to execute GenerateWebIDLBindings.py
As an example, the following shell command generates (or regenerates if one exists) the webidl bindings
for the `runtime` API namespace:
.. code-block:: sh
.. code-block:: bash
$ export SCRIPT_DIR="toolkit/components/extensions/webidl-api"
$ mach python $SCRIPT_DIR/GenerateWebIDLBindings.py -- runtime
@ -38,7 +38,7 @@ this command will generates a `.webdil` file named `dom/webidl/ExtensionRuntime.
offer to print a diff of the changes (or just continue without changing the existing webidl file
if the content is exactly the same):
.. code-block::
.. code-block:: console
$ mach python $SCRIPT_DIR/GenerateWebIDLBindings.py -- runtime

2
toolkit/components/extensions/docs/webext-storage.rst
View File

@ -83,7 +83,7 @@ For example, this interface defines the following method:
As you will notice, the 3rd arg is another interface, `mozIExtensionStorageCallback`, also
defined in that IDL file. This is a small, generic interface defined as:
.. code-block::
.. code-block:: cpp
interface mozIExtensionStorageCallback : nsISupports {
// Called when the operation completes. Operations that return a result,

4
toolkit/components/extensions/docs/webidl_bindings.rst
View File

@ -201,7 +201,7 @@ While running the test files locally they will be executed once for each manifes
where they are included, to restrict the run to just the "background service
workers mode" specify the ``sw-webextensions`` tag:
.. code-block::
.. code-block:: bash
mach xpcshell-test --tag sw-webextensions path/to/test/file.js
@ -241,6 +241,6 @@ While executing the test files locally they will run once for each manifest file
where they are included, to restrict the run to just the "background service
workers mode" specify the ``sw-webextensions`` tag:
.. code-block::
.. code-block:: bash
mach mochitest --tag sw-webextensions path/to/test/file.js

14
toolkit/components/extensions/docs/wiring_up_new_webidl_bindings.rst
View File

@ -9,7 +9,7 @@ added in alphabetic order and nearby the other WebExtensions API bindings alread
(look for the ``ExtensionBrowser`` webidl definition and the other existing WebIDL bindings related to the
WebExtensions APIs):
.. code-block::
.. code-block:: text
# WebExtension API
...
@ -33,12 +33,12 @@ The new ``.webidl`` file has to be also listed in "dom/webidl/moz.build", it sho
API bindings, **if the generated `.webidl` includes preprocessing macros** (e.g. when part of an API
is not available in all builds, e.g. subset of APIs that are only available in Desktop builds).
.. code-block::
.. code-block:: text
# WebExtensions API.
WEBIDL_FILES += [
...
"ExtensionRuntime.webidl"
"ExtensionRuntime.webidl",
...
]
@ -62,7 +62,7 @@ where the other WebIDL bindings are being listed. Similarly, the new ``.h`` coun
``EXPORTS.mozilla.extensions`` (which ensures that the header file will be placed into the path set earlier
in ``dom/bindings/Bindings.conf``):
.. code-block::
.. code-block:: text
# WebExtensions API namespaces.
UNIFIED_SOURCES += [
@ -83,7 +83,7 @@ Wiring up the new API into ``dom/webidl/ExtensionBrowser.webidl``
To make the new WebIDL bindings part of the ``browser`` global, a new attribute has to be added to
``dom/webidl/ExtensionBrowser.webidl``:
.. code-block::
.. code-block:: cpp
// `browser.runtime` API namespace.
[Replaceable, SameObject, BinaryName="GetExtensionRuntime",
@ -103,7 +103,7 @@ C++ class as defined in ``toolkit/components/extensions/webidl-api/ExtensionBrow
- the definition of a new corresponding **public method** (by convention named ``GetExtensionMyNamespace``)
- a ``RefPtr`` as a new **private data member named** (by convention named ``mExtensionMyNamespace``)
.. code-block::
.. code-block:: cpp
...
namespace extensions {
@ -130,7 +130,7 @@ And then in its ``toolkit/components/extensions/webidl-api/ExtensionBrowser.cpp`
- the addition of the new private member data ``RefPtr`` in the ``NS_IMPL_CYCLE_COLLECTION_UNLINK``
and ``NS_IMPL_CYCLE_COLLECTION_TRAVERSE`` macros
.. code-block::
.. code-block:: cpp
...
#include "mozilla/extensions/ExtensionRuntime.h"

4
toolkit/components/glean/docs/dev/new_metric_types.md
View File

@ -223,7 +223,7 @@ Add a notice at the top of both examples that these APIs are only available in F
> **Note**: C++ APIs are only available in Firefox Desktop.
```c++
```cpp
#include "mozilla/glean/GleanMetrics.h"
mozilla::glean::category_name::metric_name.Api(args);
@ -231,7 +231,7 @@ mozilla::glean::category_name::metric_name.Api(args);
There are test APIs available too:
```c++
```cpp
#include "mozilla/glean/GleanMetrics.h"
ASSERT_EQ(value, mozilla::glean::category_name::metric_name.TestGetValue().ref());

2
toolkit/components/prompts/docs/modalTypes.rst
View File

@ -47,7 +47,7 @@ When the user closes the tab or navigates to a different URI, prompts associated
with the given tab are closed.
In this case an exception will be thrown:
.. code-block::
.. code-block:: JavaScript
/*
Exception: prompt aborted by user

6
toolkit/components/prompts/docs/nsIPromptService.rst
View File

@ -104,7 +104,7 @@ The same prompt as above, but called async:
C++ Sync
~~~~~~~~
.. code-block:: c++
.. code-block:: cpp
nsCOMPtr<nsIPromptService> promptSvc =
do_GetService("@mozilla.org/prompter;1");
@ -135,7 +135,7 @@ C++ Sync
C++ Async
~~~~~~~~~
.. code-block:: c++
.. code-block:: cpp
nsCOMPtr<nsIPromptService> promptSvc =
do_GetService("@mozilla.org/prompter;1");
@ -165,7 +165,7 @@ C++ Async
Then, in your promise handler callback function:
.. code-block:: c++
.. code-block:: cpp
void PromptHandler::ResolvedCallback(JSContext* aCx,
JS::Handle<JS::Value> aValue) {

46
tools/profiler/docs/markers-guide.rst
View File

@ -19,7 +19,7 @@ Short example, details below.
Note: Most marker-related identifiers are in the ``mozilla`` namespace, to be added where necessary.
.. code-block:: c++
.. code-block:: cpp
// Record a simple marker with the category of DOM.
PROFILER_MARKER_UNTYPED("Marker Name", DOM);
@ -30,7 +30,7 @@ Note: Most marker-related identifiers are in the ``mozilla`` namespace, to be ad
// Record a custom marker of type `ExampleNumberMarker` (see definition below).
PROFILER_MARKER("Number", OTHER, MarkerOptions{}, ExampleNumberMarker, 42);
.. code-block:: c++
.. code-block:: cpp
// Marker type definition.
struct ExampleNumberMarker {
@ -60,7 +60,7 @@ Header to Include
If the compilation unit only defines and records untyped, text, and/or its own markers, include
`the main profiler markers header <https://searchfox.org/mozilla-central/source/tools/profiler/public/ProfilerMarkers.h>`_:
.. code-block:: c++
.. code-block:: cpp
#include "mozilla/ProfilerMarkers.h"
@ -68,7 +68,7 @@ If it also records one of the other common markers defined in
`ProfilerMarkerTypes.h <https://searchfox.org/mozilla-central/source/tools/profiler/public/ProfilerMarkerTypes.h>`_,
include that one instead:
.. code-block:: c++
.. code-block:: cpp
#include "mozilla/ProfilerMarkerTypes.h"
@ -76,7 +76,7 @@ And if it uses any other profiler functions (e.g., labels), use
`the main Gecko Profiler header <https://searchfox.org/mozilla-central/source/tools/profiler/public/GeckoProfiler.h>`_
instead:
.. code-block:: c++
.. code-block:: cpp
#include "GeckoProfiler.h"
@ -84,7 +84,7 @@ The above works from source files that end up in libxul, which is true for the m
of Firefox source code. But some files live outside of libxul, such as mfbt, in which
case the advice is the same but the equivalent headers are from the Base Profiler instead:
.. code-block:: c++
.. code-block:: cpp
#include "mozilla/BaseProfilerMarkers.h" // Only own/untyped/text markers
#include "mozilla/BaseProfilerMarkerTypes.h" // Only common markers
@ -96,7 +96,7 @@ Untyped Markers
Untyped markers don't carry any information apart from common marker data:
Name, category, options.
.. code-block:: c++
.. code-block:: cpp
PROFILER_MARKER_UNTYPED(
// Name, and category pair.
@ -151,7 +151,7 @@ Text Markers
Text markers are very common, they carry an extra text as a fourth argument, in addition to
the marker name. Use the following macro:
.. code-block:: c++
.. code-block:: cpp
PROFILER_MARKER_TEXT(
// Name, category pair, options.
@ -173,7 +173,7 @@ Other Typed Markers
From C++ code, a marker of some type ``YourMarker`` (details about type definition follow) can be
recorded like this:
.. code-block:: c++
.. code-block:: cpp
PROFILER_MARKER(
"YourMarker name", OTHER,
@ -193,7 +193,7 @@ After the first three common arguments (like in ``PROFILER_MARKER_UNTYPED``), th
To capture time intervals around some important operations, it is common to store a timestamp, do the work,
and then record a marker, e.g.:
.. code-block:: c++
.. code-block:: cpp
void DoTimedWork() {
TimeStamp start = TimeStamp::Now();
@ -208,7 +208,7 @@ This is especially useful if there are multiple scope exit points.
``AUTO_PROFILER_MARKER_TEXT`` is `the only one implemented <https://searchfox.org/mozilla-central/search?q=id%3AAUTO_PROFILER_MARKER_TEXT`_ at this time.
.. code-block:: c++
.. code-block:: cpp
void MaybeDoTimedWork(bool aDoIt) {
AUTO_PROFILER_MARKER_TEXT("Timed work", OTHER, "Details");
@ -249,7 +249,7 @@ markers of that type in C++.
By convention, the suffix "Marker" is recommended to better distinguish them
from non-profiler entities in the source.
.. code-block:: c++
.. code-block:: cpp
struct YourMarker {
@ -262,7 +262,7 @@ markers in the profiler storage, and to identify them uniquely on profiler.firef
This name is defined in a special static member function ``MarkerTypeName``:
.. code-block:: c++
.. code-block:: cpp
// …
static constexpr Span<const char> MarkerTypeName() {
@ -284,7 +284,7 @@ The first function parameters is always ``SpliceableJSONWriter& aWriter``,
it will be used to stream the data as JSON, to later be read by
profiler.firefox.com.
.. code-block:: c++
.. code-block:: cpp
// …
static void StreamJSONMarkerData(SpliceableJSONWriter& aWriter,
@ -310,7 +310,7 @@ in binary form (i.e., there are no optimizable ``move`` operations).
For example, here's how to handle a string, a 64-bit number, another string, and
a timestamp:
.. code-block:: c++
.. code-block:: cpp
// …
const ProfilerString8View& aString,
@ -334,7 +334,7 @@ how it should be displayed on profiler.firefox.com (see next section).
Here's how the above functions parameters could be streamed:
.. code-block:: c++
.. code-block:: cpp
// …
aWriter.StringProperty("myString", aString);
@ -355,7 +355,7 @@ displayed on profiler.firefox.com.
The static member function ``MarkerTypeDisplay`` returns an opaque ``MarkerSchema``
object, which will be forwarded to profiler.firefox.com.
.. code-block:: c++
.. code-block:: cpp
// …
static MarkerSchema MarkerTypeDisplay() {
@ -363,7 +363,7 @@ object, which will be forwarded to profiler.firefox.com.
The ``MarkerSchema`` type will be used repeatedly, so for convenience we can define
a local type alias:
.. code-block:: c++
.. code-block:: cpp
// …
using MS = MarkerSchema;
@ -377,7 +377,7 @@ full list <https://searchfox.org/mozilla-central/define?q=T_mozilla%3A%3AMarkerS
Here is the most common set of locations, showing markers of that type in both the
Marker Chart and the Marker Table panels:
.. code-block:: c++
.. code-block:: cpp
// …
MS schema(MS::Location::MarkerChart, MS::Location::MarkerTable);
@ -394,7 +394,7 @@ The arguments is a string that may refer to marker data within braces:
For example, here's how to set the Marker Chart label to show the marker name and the
``myBytes`` number of bytes:
.. code-block:: c++
.. code-block:: cpp
// …
schema.SetChartLabel("{marker.name} – {marker.data.myBytes}");
@ -424,7 +424,7 @@ Each row may either be:
* Or a fixed label and value strings, using ``MarkerSchema::AddStaticLabelValue``.
.. code-block:: c++
.. code-block:: cpp
// …
schema.AddKeyLabelFormatSearchable(
@ -438,7 +438,7 @@ Each row may either be:
Finally the ``schema`` object is returned from the function:
.. code-block:: c++
.. code-block:: cpp
// …
return schema;
@ -449,7 +449,7 @@ compulsory functions, to make the code clearer.
And that is the end of the marker definition ``struct``.
.. code-block:: c++
.. code-block:: cpp
// …
};

6
tools/sanitizer/docs/memory_sanitizer.rst
View File

@ -64,7 +64,7 @@ Adjusting the build configuration
Create the build configuration file ``.mozconfig`` with the following
content in your Mozilla-central directory:
.. code::
.. code:: bash
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-ff-msan
@ -139,7 +139,7 @@ execute this script in the ``js/src/`` subdirectory and pass a directory
name as the first parameter. The build will then be created in a new
subdirectory with that name.
.. code::
.. code:: bash
#! /bin/sh
@ -156,7 +156,7 @@ subdirectory with that name.
CXX="$LLVM_ROOT/build/bin/clang++" \
CFLAGS="-fsanitize=memory" \
CXXFLAGS="-fsanitize=memory" \
LDFLAGS=""-fsanitize=memory" \
LDFLAGS="-fsanitize=memory" \
../configure --enable-debug --enable-optimize --enable-memory-sanitizer --disable-jemalloc --enable-posix-nspr-emulation
make -j 8
fi

2
tools/tryselect/docs/selectors/auto.rst
View File

@ -12,7 +12,7 @@ tasks should run on your push.
To use:
.. code-block::
.. code-block:: bash
$ mach try auto

4
xpcom/docs/logging.rst
View File

@ -408,7 +408,7 @@ Declaring a Log Module
Note: Log module names can only contain specific characters. The first character must be a lowercase or uppercase ASCII char, underscore, dash, or dot. Subsequent characters may be any of those, or an ASCII digit.
.. code-block:: c++
.. code-block:: cpp
#include "mozilla/Logging.h"
@ -455,7 +455,7 @@ A basic interface is provided in the form of 2 macros and an enum class.
Example Usage
-------------
.. code-block:: c++
.. code-block:: cpp
#include "mozilla/Logging.h"

48
xpcom/docs/stringguide.rst
View File

@ -130,7 +130,7 @@ As function parameters
In general, use ``nsA[C]String`` references to pass strings across modules. For example:
.. code-block:: c++
.. code-block:: cpp
// when passing a string to a method, use const nsAString&
nsFoo::PrintString(const nsAString& str);
@ -204,7 +204,7 @@ Iterators
Because Mozilla strings are always a single buffer, iteration over the
characters in the string is done using raw pointers:
.. code-block:: c++
.. code-block:: cpp
/**
* Find whether there is a tab character in `data`
@ -226,7 +226,7 @@ It should never be dereferenced.
Writing to a mutable string is also simple:
.. code-block:: c++
.. code-block:: cpp
/**
* Replace every tab character in `data` with a space.
@ -247,7 +247,7 @@ Iterators become invalid after changing the length of a string. If a string
buffer becomes smaller while writing it, use ``SetLength`` to inform the
string class of the new size:
.. code-block:: c++
.. code-block:: cpp
/**
* Remove every tab character from `data`
@ -353,7 +353,7 @@ Searching strings - looking for substrings, characters, etc.
The ``nsReadableUtils.h`` header provides helper methods for searching in runnables.
.. code-block:: c++
.. code-block:: cpp
bool FindInReadable(const nsAString& pattern,
nsAString::const_iterator start, nsAString::const_iterator end,
@ -367,7 +367,7 @@ whether or not the string was found.
An example:
.. code-block:: c++
.. code-block:: cpp
const nsAString& str = GetSomeString();
nsAString::const_iterator start, end;
@ -403,7 +403,7 @@ actually allocating new space and copying the characters into that substring.
``Substring()`` is the preferred method to create a reference to such a
string.
.. code-block:: c++
.. code-block:: cpp
void ProcessString(const nsAString& str) {
const nsAString& firstFive = Substring(str, 0, 5); // from index 0, length 5
@ -534,7 +534,7 @@ UTF-8 / UTF-16 conversion
or ``const char*`` to a 16-bit UTF-16 string. If you need a ``const
char16_t*`` buffer, you can use the ``.get()`` method. For example:
.. code-block:: c++
.. code-block:: cpp
/* signature: void HandleUnicodeString(const nsAString& str); */
object->HandleUnicodeString(NS_ConvertUTF8toUTF16(utf8String));
@ -548,7 +548,7 @@ UTF-8 / UTF-16 conversion
to a UTF-8 encoded string. As above, you can use ``.get()`` to access a
``const char*`` buffer.
.. code-block:: c++
.. code-block:: cpp
/* signature: void HandleUTF8String(const nsACString& str); */
object->HandleUTF8String(NS_ConvertUTF16toUTF8(utf16String));
@ -560,7 +560,7 @@ UTF-8 / UTF-16 conversion
converts and copies:
.. code-block:: c++
.. code-block:: cpp
// return a UTF-16 value
void Foo::GetUnicodeValue(nsAString& result) {
@ -571,7 +571,7 @@ UTF-8 / UTF-16 conversion
converts and appends:
.. code-block:: c++
.. code-block:: cpp
// return a UTF-16 value
void Foo::GetUnicodeValue(nsAString& result) {
@ -583,7 +583,7 @@ UTF-8 / UTF-16 conversion
converts and copies:
.. code-block:: c++
.. code-block:: cpp
// return a UTF-8 value
void Foo::GetUTF8Value(nsACString& result) {
@ -594,7 +594,7 @@ UTF-8 / UTF-16 conversion
converts and appends:
.. code-block:: c++
.. code-block:: cpp
// return a UTF-8 value
void Foo::GetUnicodeValue(nsACString& result) {
@ -709,7 +709,7 @@ advantage of the user-defined literals is twofold.
Here are some examples of proper usage of the literals (both standard and
user-defined):
.. code-block:: c++
.. code-block:: cpp
// call Init(const nsLiteralString&) - enforces that it's only called with literals
Init(u"start value"_ns);
@ -746,7 +746,7 @@ least as long as the ``nsSubstringTuple`` object.
For example, you can use the value of two strings and pass their
concatenation on to another function which takes an ``const nsAString&``:
.. code-block:: c++
.. code-block:: cpp
void HandleTwoStrings(const nsAString& one, const nsAString& two) {
// call HandleString(const nsAString&)
@ -760,7 +760,7 @@ buffer will be shared in this case negating the cost of the intermediate
temporary. You can concatenate N strings and store the result in a temporary
variable:
.. code-block:: c++
.. code-block:: cpp
constexpr auto start = u"start "_ns;
constexpr auto middle = u"middle "_ns;
@ -775,7 +775,7 @@ It is safe to concatenate user-defined literals because the temporary
``nsLiteral[C]String`` objects will live as long as the temporary
concatenation object (of type ``nsSubstringTuple``).
.. code-block:: c++
.. code-block:: cpp
// call HandlePage(const nsAString&);
// safe because the concatenated-string will live as long as its substrings
@ -794,7 +794,7 @@ dealing with small strings. ``nsAutoStringN``/``nsAutoCStringN`` are more
general alternatives that let you choose the number of characters in the
inline buffer.
.. code-block:: c++
.. code-block:: cpp
...
nsAutoString value;
@ -808,7 +808,7 @@ Member Variables
In general, you should use the concrete classes ``nsString`` and
``nsCString`` for member variables.
.. code-block:: c++
.. code-block:: cpp
class Foo {
...
@ -836,7 +836,7 @@ buffer if necessary. This is most often used in order to pass an
In the following example, an ``nsAString`` is combined with a literal string,
and the result is passed to an API which requires a simple character buffer.
.. code-block:: c++
.. code-block:: cpp
// Modify the URL and pass to AddPage(const char16_t* url)
void AddModifiedPage(const nsAString& url) {
@ -850,7 +850,7 @@ and the result is passed to an API which requires a simple character buffer.
``PromiseFlatString()`` is smart when handed a string that is already
null-terminated. It avoids creating the temporary buffer in such cases.
.. code-block:: c++
.. code-block:: cpp
// Modify the URL and pass to AddPage(const char16_t* url)
void AddModifiedPage(const nsAString& url, PRBool addPrefix) {
@ -881,7 +881,7 @@ For debugging, it's useful to ``printf`` a UTF-16 string (``nsString``,
``nsAutoString``, etc). To do this usually requires converting it to an 8-bit
string, because that's what ``printf`` expects. Use:
.. code-block:: c++
.. code-block:: cpp
printf("%s\n", NS_ConvertUTF16toUTF8(yourString).get());
@ -983,14 +983,14 @@ In XPIDL, ``in`` parameters are read-only, and the C++ signatures for
nsAString&`` for these parameters. ``out`` and ``inout`` parameters are
defined simply as ``nsAString&`` so that the callee can write to them.
.. code-block::
.. code-block:: cpp
interface nsIFoo : nsISupports {
attribute AString utf16String;
AUTF8String getValue(in ACString key);
};
.. code-block:: c++
.. code-block:: cpp
class nsIFoo : public nsISupports {
NS_IMETHOD GetUtf16String(nsAString& aResult) = 0;

4
xpcom/docs/xpidl.rst
View File

@ -122,7 +122,7 @@ WebIDL Interfaces
WebIDL interfaces are also valid XPIDL types. To declare a WebIDL interface in
XPIDL, write:
.. code-block::
.. code-block:: JavaScript
webidl InterfaceName;
@ -148,7 +148,7 @@ the ``cenum`` construct can be used to group constants together. Constants
grouped in a ``cenum`` will be reflected as-if they were declared directly on
the interface, in Rust and Javascript code.
.. code-block::
.. code-block:: JavaScript
cenum MyCEnum : 8 {
eSomeValue, // starts at 0