fix links

docs/source/contribute.rst

@@ -22,7 +22,7 @@ The definition holds the signature of the function. In the correct tier's header
 
     auto my_operation_func(const Device::Pointer &device, const Array::Pointer &src, Array::Pointer &dst, float param1, int param2) -> Array::Pointer;
 
-The function must follow several rules. First, the function name should be suffixed with ``_func`` and use the `trailing return <https://en.wikipedia.org/wiki/Trailing_return_type>__` syntax. 
+The function must follow several rules. First, the function name should be suffixed with ``_func`` and use the `trailing return <https://en.wikipedia.org/wiki/Trailing_return_type>`__ syntax. 
 The first parameter should always be a ``const Device::Pointer& device``, followed by all the inputs and outputs required by the function. 
 We require that the inputs are passed as ``const Array::Pointer&`` and named ``src``. The output must be an ``Array::Pointer&`` and named ``dst``. 
 If multiple inputs or outputs are needed, an index is added to the name, e.g., ``src0``, ``src1``, ``dst0``, ``dst1``. 
@@ -226,7 +226,7 @@ This means that the kernels are compiled and run at runtime.
 This is a very powerful feature as it allows writing GPU code in a flexible way, adapted to your data size and time requirements, but it requires a bit of preparation for execution. 
 It will also add compilation time to the process, which can be a bit long for the first execution of a kernel but is drastically reduced for subsequent calls due to a caching system.
 
-The first thing to ensure is that the kernel code we will call is available in the `CLIJ kernel repository <https://github.com/clEsperanto/clij-opencl-kernels/tree/clesperanto_kernels>__` and respects the CLIJ convention. If this is the case, we will be able to include the kernel as a header file in the ``clic`` library. This header will contain a stringified version of the kernel code and will be passed to the ``execute`` function as a ``KernelInfo`` structure with the name of the kernel and the code of the kernel. By default, the `KernelInfo` should match the pattern `{ "kernel_name", kernel::kernel_name }`.
+The first thing to ensure is that the kernel code we will call is available in the `CLIJ kernel repository <https://github.com/clEsperanto/clij-opencl-kernels/tree/clesperanto_kernels>`__ and respects the CLIJ convention. If this is the case, we will be able to include the kernel as a header file in the ``clic`` library. This header will contain a stringified version of the kernel code and will be passed to the ``execute`` function as a ``KernelInfo`` structure with the name of the kernel and the code of the kernel. By default, the `KernelInfo` should match the pattern `{ "kernel_name", kernel::kernel_name }`.
 
 .. code-block:: cpp
     :emphasize-lines: 3, 14

docs/source/usage.rst

@@ -73,7 +73,7 @@ To create an array, we need to provide the device, the size of the array and the
     auto gpu_array = cle::Array::create(10, 5, 3, 3, cle::dType::FLOAT, cle::mType::BUFFER, device);
 
 Here we create a 3D array of size 10x5x3 of type ``float`` on the device. 
-``cle::mType::BUFFER`` is the memory type of the array, here a BUFFER (see the `Array class <https://clesperanto.github.io/CLIc/array.html>__` for more information on the memory types and methods).
+``cle::mType::BUFFER`` is the memory type of the array, here a BUFFER (see the `Array class <https://clesperanto.github.io/CLIc/array.html>`__ for more information on the memory types and methods).
 
 Here, we only created a memory space on the device, similarly as a ``malloc()`` in `C`.
 We need now to write data into the device array.

docs/source/versioning.rst

@@ -1,13 +1,13 @@
 Versioning
 ----------
 
-The versioning of this project is based on the `Semantic Versioning Specification <http://semver.org/>__`.
+The versioning of this project is based on the `Semantic Versioning Specification <http://semver.org/>`__.
 
 Semantic Versions are in the format: ``MAJOR.MINOR.PATCH``.
 
    - :If you have fixed a bug: increase the patch version
    - :If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
    - :If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
 
-The project version is managed in the `CMakelists.txt <https://github.com/clEsperanto/CLIc/blob/master/CMakeLists.txt>__` file at the root of the repository.
+The project version is managed in the `CMakelists.txt <https://github.com/clEsperanto/CLIc/blob/master/CMakeLists.txt>`__ file at the root of the repository.