docs/

Enhancing all the .rst doc files by adding highlighting for the code snippets, including the following langs:
1. Solidity

2. bash

3. javascript

4. assembly

docs/contracts/abstract-contracts.rst

@@ -11,7 +11,9 @@ Contracts may be marked as abstract even though all functions are implemented.
 
 This can be done by using the ``abstract`` keyword as shown in the following example. Note that this contract needs to be
 defined as abstract, because the function ``utterance()`` was defined, but no implementation was
-provided (no implementation body ``{ }`` was given).::
+provided (no implementation body ``{ }`` was given).
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -21,7 +23,9 @@ provided (no implementation body ``{ }`` was given).::
     }
 
 Such abstract contracts can not be instantiated directly. This is also true, if an abstract contract itself does implement
-all defined functions. The usage of an abstract contract as a base class is shown in the following example::
+all defined functions. The usage of an abstract contract as a base class is shown in the following example:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -40,11 +44,15 @@ functions by overriding, it needs to be marked as abstract as well.
 Note that a function without implementation is different from
 a :ref:`Function Type <function_types>` even though their syntax looks very similar.
 
-Example of function without implementation (a function declaration)::
+Example of function without implementation (a function declaration):
+
+.. code-block:: solidity
 
     function foo(address) external returns (address);
 
-Example of a declaration of a variable whose type is a function type::
+Example of a declaration of a variable whose type is a function type:
+
+.. code-block:: solidity
 
     function(address) external returns (address) foo;
 

docs/contracts/constant-state-variables.rst

@@ -27,7 +27,7 @@ can sometimes be cheaper than immutable values.
 Not all types for constants and immutables are implemented at this time. The only supported types are
 :ref:`strings <strings>` (only for constants) and :ref:`value types <value-types>`.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.4;

docs/contracts/creating-contracts.rst

@@ -32,7 +32,7 @@ If a contract wants to create another contract, the source code
 (and the binary) of the created contract has to be known to the creator.
 This means that cyclic creation dependencies are impossible.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.22 <0.9.0;

docs/contracts/errors.rst

@@ -14,7 +14,7 @@ which causes
 all changes in the current call to be reverted and passes the error data back to the
 caller.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;
@@ -79,4 +79,4 @@ of the built-in type ``Panic(uint256)``.
     of inner calls is propagated back through the chain of external calls
     by default. This means that an inner call
     can "forge" revert data that looks like it could have come from the
-    contract that called it.
+    contract that called it.

docs/contracts/function-modifiers.rst

@@ -15,7 +15,7 @@ inheritable properties of contracts and may be overridden by derived contracts,
 if they are marked ``virtual``. For details, please see
 :ref:`Modifier Overriding <modifier-overriding>`.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >0.7.0 <0.9.0;

docs/contracts/functions.rst

@@ -12,7 +12,7 @@ Functions outside of a contract, also called "free functions", always have impli
 :ref:`visibility<visibility-and-getters>`. Their code is included in all contracts
 that call them, similar to internal library functions.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >0.7.0 <0.9.0;
@@ -56,7 +56,9 @@ Function parameters are declared the same way as variables, and the name of
 unused parameters can be omitted.
 
 For example, if you want your contract to accept one kind of external call
-with two integers, you would use something like the following::
+with two integers, you would use something like the following:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -89,7 +91,9 @@ Function return variables are declared with the same syntax after the
 ``returns`` keyword.
 
 For example, suppose you want to return two results: the sum and the product of
-two integers passed as function parameters, then you use something like::
+two integers passed as function parameters, then you use something like:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -114,7 +118,9 @@ You can either explicitly assign to return variables and
 then leave the function as above,
 or you can provide return values
 (either a single or :ref:`multiple ones<multi-return>`) directly with the ``return``
-statement::
+statement:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -178,7 +184,7 @@ The following statements are considered modifying the state:
 #. Using low-level calls.
 #. Using inline assembly that contains certain opcodes.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.5.0 <0.9.0;
@@ -224,7 +230,7 @@ In addition to the list of state modifying statements explained above, the follo
 #. Calling any function not marked ``pure``.
 #. Using inline assembly that contains certain opcodes.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.5.0 <0.9.0;
@@ -321,7 +327,7 @@ will consume more gas than the 2300 gas stipend:
 
 Below you can see an example of a Sink contract that uses function ``receive``.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -383,7 +389,7 @@ operations as long as there is enough gas passed on to it.
     proper functions should be used instead.
 
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.2 <0.9.0;
@@ -461,7 +467,7 @@ This process is called "overloading" and also applies to inherited functions.
 The following example shows overloading of the function
 ``f`` in the scope of contract ``A``.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -480,7 +486,7 @@ The following example shows overloading of the function
 Overloaded functions are also present in the external interface. It is an error if two
 externally visible functions differ by their Solidity types but not by their external types.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -514,7 +520,7 @@ candidate, resolution fails.
 .. note::
     Return parameters are not taken into account for overload resolution.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;

docs/contracts/inheritance.rst

@@ -36,7 +36,7 @@ some :ref:`differences <multi-inheritance>`.
 
 Details are given in the following example.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;
@@ -124,7 +124,9 @@ Details are given in the following example.
 
 Note that above, we call ``Destructible.destroy()`` to "forward" the
 destruction request. The way this is done is problematic, as
-seen in the following example::
+seen in the following example:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;
@@ -154,7 +156,9 @@ seen in the following example::
 
 A call to ``Final.destroy()`` will call ``Base2.destroy`` because we specify it
 explicitly in the final override, but this function will bypass
-``Base1.destroy``. The way around this is to use ``super``::
+``Base1.destroy``. The way around this is to use ``super``:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;
@@ -211,7 +215,7 @@ The mutability may be changed to a more strict one following the order:
 
 The following example demonstrates changing mutability and visibility:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;
@@ -235,7 +239,7 @@ and have not yet been overridden by another base contract (on some path through
 Additionally, if a contract inherits the same function from multiple (unrelated)
 bases, it has to explicitly override it:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -262,7 +266,7 @@ the function is defined in a common base contract
 or if there is a unique function in a common base contract
 that already overrides all other functions.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -303,7 +307,7 @@ Public state variables can override external functions if the
 parameter and return types of the function matches the getter function
 of the variable:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -335,7 +339,7 @@ Function modifiers can override each other. This works in the same way as
 ``virtual`` keyword must be used on the overridden modifier
 and the ``override`` keyword must be used in the overriding modifier:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -354,7 +358,7 @@ and the ``override`` keyword must be used in the overriding modifier:
 In case of multiple inheritance, all direct base contracts must be specified
 explicitly:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -402,7 +406,7 @@ If there is no
 constructor, the contract will assume the default constructor, which is
 equivalent to ``constructor() {}``. For example:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;
@@ -439,7 +443,9 @@ Arguments for Base Constructors
 
 The constructors of all the base contracts will be called following the
 linearization rules explained below. If the base constructors have arguments,
-derived contracts need to specify all of them. This can be done in two ways::
+derived contracts need to specify all of them. This can be done in two ways:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;
@@ -499,7 +505,7 @@ stopping at the first match. If a base contract has already been searched, it is
 In the following code, Solidity will give the
 error "Linearization of inheritance graph impossible".
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.0 <0.9.0;
@@ -520,7 +526,7 @@ C3 linearization is not too important in practice.
 
 One area where inheritance linearization is especially important and perhaps not as clear is when there are multiple constructors in the inheritance hierarchy. The constructors will always be executed in the linearized order, regardless of the order in which their arguments are provided in the inheriting contract's constructor.  For example:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.7.0 <0.9.0;

docs/contracts/interfaces.rst

@@ -20,7 +20,7 @@ an interface should be possible without any information loss.
 
 Interfaces are denoted by their own keyword:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.2 <0.9.0;
@@ -41,7 +41,7 @@ function is marked ``virtual``.
 Interfaces can inherit from other interfaces. This has the same rules as normal
 inheritance.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.2 <0.9.0;

docs/contracts/libraries.rst

@@ -50,7 +50,7 @@ The following example illustrates how to use libraries (but using a manual metho
 be sure to check out :ref:`using for <using-for>` for a
 more advanced example to implement a set).
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -129,7 +129,7 @@ The following example shows how to use :ref:`types stored in memory <data-locati
 internal functions in libraries in order to implement
 custom types without the overhead of external function calls:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.8 <0.9.0;
@@ -238,7 +238,7 @@ The argument encoding is the same as for the regular contract ABI, except for st
 Similarly to the contract ABI, the selector consists of the first four bytes of the Keccak256-hash of the signature.
 Its value can be obtained from Solidity using the ``.selector`` member as follows:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.5.14 <0.9.0;

docs/contracts/using-for.rst

@@ -27,7 +27,9 @@ outside of the contract in which it is used. The directive
 may only be used inside a contract, not inside any of its functions.
 
 Let us rewrite the set example from the
-:ref:`libraries` in this way::
+:ref:`libraries` in this way:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.0 <0.9.0;
@@ -80,7 +82,9 @@ Let us rewrite the set example from the
         }
     }
 
-It is also possible to extend elementary types in that way::
+It is also possible to extend elementary types in that way:
+
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.6.8 <0.9.0;

docs/contracts/visibility-and-getters.rst

@@ -50,7 +50,7 @@ The visibility specifier is given after the type for
 state variables and between parameter list and
 return parameter list for functions.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -65,7 +65,7 @@ In the following example, ``D``, can call ``c.getData()`` to retrieve the value
 ``data`` in state storage, but is not able to call ``f``. Contract ``E`` is derived from
 ``C`` and, thus, can call ``compute``.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -110,7 +110,7 @@ arguments and returns a ``uint``, the value of the state
 variable ``data``. State variables can be initialized
 when they are declared.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -131,7 +131,7 @@ symbol is accessed internally (i.e. without ``this.``),
 it evaluates to a state variable.  If it is accessed externally
 (i.e. with ``this.``), it evaluates to a function.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.0 <0.9.0;
@@ -151,7 +151,7 @@ arguments to specify which individual element to return, for example
 ``myArray(0)``. If you want to return an entire array in one call, then you need
 to write a function, for example:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -178,7 +178,7 @@ Now you can use ``getArray()`` to retrieve the entire array, instead of
 
 The next example is more complex:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.0 <0.9.0;
@@ -195,7 +195,7 @@ The next example is more complex:
 It generates a function of the following form. The mapping in the struct is omitted
 because there is no good way to provide the key for the mapping:
 
-::
+.. code-block:: solidity
 
     function data(uint arg1, bool arg2, uint arg3) public returns (uint a, bytes3 b) {
         a = data[arg1][arg2][arg3].a;