Fix errata in documentation

This patch addresses the following errata found in the project documentation:

* Common typos.
* Missing use of trademarks.
* Incomplete operator descriptions.
* Examples of code that have since been removed from the library.
* Plus clarification over the usage of `All` category for data types and layouts.

In addition, the Operator list was not generated properly due to:

* Non-matching cases in the filenames (i.e. `Elementwise` and `ElementWise`). For consistency, all usages of the latter have been renamed to the former.
* Extra data layout tables in the headers for the `NESlice` and `NEStridedSlice` functions (note: not present in CL counterpart) meant documentation for those functions was generated twice.

Resolves: COMPMID-4561, COMPMID-4562, COMPMID-4563
Change-Id: I1eb24559545397749e636ffbf927727fb1bc6201
Signed-off-by: Jakub Sujak <jakub.sujak@arm.com>
Reviewed-on: https://review.mlplatform.org/c/ml/ComputeLibrary/+/5769
Comments-Addressed: Arm Jenkins <bsgcomp@arm.com>
Tested-by: Arm Jenkins <bsgcomp@arm.com>
Reviewed-by: Sheri Zhang <sheri.zhang@arm.com>
Reviewed-by: SiCong Li <sicong.li@arm.com>

2 files changed, 11 insertions, 11 deletions

diff --git a/docs/contributor_guide/adding_operator.dox b/docs/contributor_guide/adding_operator.dox
index 67e6fbd25b..772d4362c8 100644
--- a/docs/contributor_guide/adding_operator.dox
+++ b/docs/contributor_guide/adding_operator.dox
@@ -75,10 +75,10 @@ Similarly, all common functions that process shapes, like calculating output sha
 @subsection S4_1_2_add_kernel Add a kernel
 As we mentioned at the beginning, the kernel is the implementation of the operator or algorithm partially using a specific programming language related to the backend we want to use. Adding a kernel in the library means implementing the algorithm in a SIMD technology like Arm® Neon™ or OpenCL. All kernels in Compute Library must implement a common interface IKernel or one of the specific subinterfaces.
 IKernel is the common interface for all the kernels in the core library, it contains the main methods for configure and run the kernel itself, such as window()  that return the maximum window the kernel can be executed on or is_parallelisable() for indicate whether or not the kernel is parallelizable. If the kernel is parallelizable then the window returned by the window() method can be split into sub-windows which can then be run in parallel, in the other case, only the window returned by window() can be passed to the run method.
-There are specific interfaces for OpenCL and Neon: @ref ICLKernel, INEKernel (using INEKernel = @ref ICPPKernel).
+There are specific interfaces for OpenCL and Neon™: @ref ICLKernel, INEKernel (using INEKernel = @ref ICPPKernel).
 
 - @ref ICLKernel is the common interface for all the OpenCL kernels. It implements the inherited methods and adds all the methods necessary to configure the CL kernel, such as set/return the Local-Workgroup-Size hint, add single, array or tensor argument, set the targeted GPU architecture according to the CL device. All these methods are used during the configuration and the run of the operator.
-- INEKernel inherits from @ref IKernel as well and it's the common interface for all kernels implemented in Neon, it adds just the run and the name methods.
+- INEKernel inherits from @ref IKernel as well and it's the common interface for all kernels implemented in Neon™, it adds just the run and the name methods.
 
 There are two others implementation of @ref IKernel called @ref ICLSimpleKernel and INESimpleKernel, they are the interface for simple kernels that have just one input tensor and one output tensor.
 Creating a new kernel implies adding new files:
@@ -87,7 +87,7 @@ Creating a new kernel implies adding new files:
 - src/core/CL/kernels/CLReshapeLayerKernel.cpp
 - src/core/CL/CLKernelLibrary.cpp
 
-Neon kernel
+Neon™ kernel
 - arm_compute/core/NEON/kernels/NEReshapeLayerKernel.h
 - src/core/NEON/kernels/NEReshapeLayerKernel.cpp
 
@@ -153,7 +153,7 @@ OpenCL function
 - arm_compute/runtime/CL/functions/CLReshapeLayer.h
 - src/runtime/CL/functions/CLReshapeLayer.cpp
 
-Neon function
+Neon™ function
 - arm_compute/runtime/NEON/functions/NEReshapeLayer.h
 - src/runtime/NEON/functions/NEReshapeLayer.cpp
 
@@ -216,7 +216,7 @@ void CLAddReshapeLayer::run()
 
 @endcode
 
-For Neon:
+For Neon™:
 
 @code{.cpp}
 using namespace arm_compute;
@@ -264,7 +264,7 @@ At this point, everything is in place at the library level. If you are following
 
 @subsubsection S4_1_4_1_add_reference Add the reference implementation and the tests
 As mentioned in the introduction, the reference implementation is a pure C++ implementation without any optimization or backend specific instruction.
-The refence implementation consist of two files into the folder tests/validation/reference:
+The reference implementation consist of two files into the folder tests/validation/reference:
 - tests/validation/reference/ReshapeLayer.h
 - tests/validation/reference/ReshapeLayer.cpp
 
@@ -300,7 +300,7 @@ For example, dataset for ReshapeLayer:
 
 Benchmark and validation tests are based on the same framework to setup and run the tests. In addition to running simple, self-contained test functions the framework supports fixtures and data test cases.
 Fixtures can be used to share common setup, teardown or even run tasks among multiple test cases, for that purpose a fixture can define a "setup", "teardown" and "run" method.
-Adding tests for the new operator in the runtime library we need to implement at least the setup method, that is used to call two methods for configure, run and return the output respectively of the target (CL or Neon) and the reference (C++ implementation).
+Adding tests for the new operator in the runtime library we need to implement at least the setup method, that is used to call two methods for configure, run and return the output respectively of the target (CL or Neon™) and the reference (C++ implementation).
 
 For example let's have a look at Reshape Layer Fixture :
 
@@ -310,7 +310,7 @@ In the fixture class above we can see that the setup method computes the target
 The compute_target method reflects the exact behavior expected when we call a function. The input and output tensor must be declared, function configured, tensors allocated, the input tensor filled with required data, and finally, the function must be run and the results returned.
 This fixture is used in the test case, that is a parameterized test case that inherits from a fixture. The test case will have access to all public and protected members of the fixture. Only the setup and teardown methods of the fixture will be used. The setup method of the fixture needs to be a template and must accept inputs from the dataset as arguments.
 The body of this function will be used as a test function.
-For the fixture test case the first argument is the name of the test case (has to be unique within the enclosing test suite), the second argument is the class name of the fixture, the third argument is the dataset mode in which the test will be active (PRECOMMIT or NIGTHLY) and the fourth argument is the dataset.
+For the fixture test case the first argument is the name of the test case (has to be unique within the enclosing test suite), the second argument is the class name of the fixture, the third argument is the dataset mode in which the test will be active (PRECOMMIT or NIGHTLY) and the fourth argument is the dataset.
 For example:
 
 @snippet tests/validation/CL/ActivationLayer.cpp CLActivationLayerFixture snippet
diff --git a/docs/contributor_guide/contribution_guidelines.dox b/docs/contributor_guide/contribution_guidelines.dox
index ec3e3a70d3..f3a6def582 100644
--- a/docs/contributor_guide/contribution_guidelines.dox
+++ b/docs/contributor_guide/contribution_guidelines.dox
@@ -139,11 +139,11 @@ void foobar(const MyLargeCustomTypeClass &m); // Definitely better as const-refe
 
 - Don't use unions
 
-Unions cannot be used to convert values between different types because (in C++) it is undefined behaviour to read from a member other than the last one that has been assigned to. This limits the use of unions to a few corner cases and therefor the general advice is not to use unions. See http://releases.llvm.org/3.8.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.html
+Unions cannot be used to convert values between different types because (in C++) it is undefined behaviour to read from a member other than the last one that has been assigned to. This limits the use of unions to a few corner cases and therefore the general advice is not to use unions. See http://releases.llvm.org/3.8.0/tools/clang/tools/extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-union-access.html
 
 - Use pre-increment/pre-decrement whenever possible
 
-In contrast to the pre-incerement the post-increment has to make a copy of the incremented object. This might not be a problem for primitive types like int but for class like objects that overload the operators, like iterators, it can have a huge impact on the performance. See http://stackoverflow.com/a/9205011
+In contrast to the pre-increment the post-increment has to make a copy of the incremented object. This might not be a problem for primitive types like int but for class like objects that overload the operators, like iterators, it can have a huge impact on the performance. See http://stackoverflow.com/a/9205011
 
 To be consistent across the different cases the general advice is to use the pre-increment operator unless post-increment is explicitly required. The same rules apply for the decrement operator.
 
@@ -438,7 +438,7 @@ You are now ready to submit your patch for review:
 
 @section S5_3_code_review Patch acceptance and code review
 
-Once a patch is uploaded for review, there is a pre-commit test that runs on a Jenkins server for continuos integration tests. In order to be merged a patch needs to:
+Once a patch is uploaded for review, there is a pre-commit test that runs on a Jenkins server for continuous integration tests. In order to be merged a patch needs to:
 
 - get a "+1 Verified" from the pre-commit job
 - get a "+1 Comments-Addressed", in case of comments from reviewers the committer has to address them all. A comment is considered addressed when the first line of the reply contains the word "Done"