[Docs]: Highlighting code snippets in .rst docs

docs/050-breaking-changes.rst

@@ -290,7 +290,7 @@ It is still possible to interface with contracts written for Solidity versions p
 v0.5.0 (or the other way around) by defining interfaces for them.
 Consider you have the following pre-0.5.0 contract already deployed:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.4.25;
@@ -308,7 +308,7 @@ Consider you have the following pre-0.5.0 contract already deployed:
 
 This will no longer compile with Solidity v0.5.0. However, you can define a compatible interface for it:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.5.0 <0.9.0;
@@ -326,7 +326,7 @@ the function will work with ``staticcall``.
 
 Given the interface defined above, you can now easily use the already deployed pre-0.5.0 contract:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.5.0 <0.9.0;
@@ -347,7 +347,7 @@ Similarly, pre-0.5.0 libraries can be used by defining the functions of the libr
 supplying the address of the pre-0.5.0 library during linking (see :ref:`commandline-compiler` for how to use the
 commandline compiler for linking):
 
-::
+.. code-block:: solidity
 
     // This will not compile after 0.6.0
     // SPDX-License-Identifier: GPL-3.0
@@ -372,7 +372,7 @@ v0.5.0 with some of the changes listed in this section.
 
 Old version:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.4.25;
@@ -435,7 +435,7 @@ Old version:
 
 New version:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.5.0;

docs/abi-spec.rst

@@ -235,7 +235,7 @@ Examples
 
 Given the contract:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -510,7 +510,7 @@ call.
 As an example, let us consider the following contract whose ``transfer`` function always
 reverts with a custom error of "insufficient balance":
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;
@@ -599,7 +599,7 @@ Errors look as follows:
 
 For example,
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;
@@ -653,7 +653,7 @@ which is of array type and has the same structure as the top-level object except
 
 As an example, the code
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >0.7.4 <0.9.0;

docs/assembly.rst

@@ -39,7 +39,7 @@ load it into a ``bytes`` variable. This is not possible with "plain Solidity" an
 idea is that reusable assembly libraries can enhance the Solidity language
 without a compiler change.
 
-.. code::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -65,7 +65,7 @@ without a compiler change.
 Inline assembly is also beneficial in cases where the optimizer fails to produce
 efficient code, for example:
 
-.. code::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity >=0.4.16 <0.9.0;
@@ -217,7 +217,9 @@ starting from where this pointer points at and update it.
 There is no guarantee that the memory has not been used before and thus
 you cannot assume that its contents are zero bytes.
 There is no built-in mechanism to release or free allocated memory.
-Here is an assembly snippet you can use for allocating memory that follows the process outlined above::
+Here is an assembly snippet you can use for allocating memory that follows the process outlined above
+
+.. code-block:: yul
 
     function allocate(length) -> pos {
       pos := mload(0x40)

docs/common-patterns.rst

@@ -25,7 +25,7 @@ contract in order to become the "richest", inspired by
 In the following contract, if you are no longer the richest,
 you receive the funds of the person who is now the richest.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;
@@ -63,7 +63,7 @@ you receive the funds of the person who is now the richest.
 
 This is as opposed to the more intuitive sending pattern:
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;
@@ -129,7 +129,7 @@ functions and this is what this section is about.
 The use of **function modifiers** makes these
 restrictions highly readable.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;
@@ -292,7 +292,7 @@ function finishes.
     Starting with version 0.4.0, modifier code
     will run even if the function explicitly returns.
 
-::
+.. code-block:: solidity
 
     // SPDX-License-Identifier: GPL-3.0
     pragma solidity ^0.8.4;

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;