[mlir] [doc] fix typos in documentation (#120179)

This PR fixes typos within documentation in various files.

Most changes are trivial. The one interesting change is the
documentation for `custom<X>` in `assemblyFormat` that used the wrong
return type. The return type from the `parseX` function should be
`ParseResult` rather than `LogicalResult`. The `ParseResult` type is
necessary due to tablegen generating code like the following within an
Op `parse()` function:
```
    auto odsResult = parseInferredArrayType(parser, elementsTypes, elementsOperands, resultRawTypes[0]);
    if (odsResult) return ::mlir::failure();
```
This will fail to compile if `parseInferredArrayType()` returns
`LogicalResult`. See also `parsePrettyLLVMType()` in LLVMTypes.h,
`parseSingleBlockRegion()` in IRDL.cpp, `parseDynamicIndexList()` in
ViewLikeInterface.cpp, etc.

Author: tim-hoffman

mlir/docs/DefiningDialects/AttributesAndTypes.md

@@ -890,7 +890,7 @@ The `custom` directive `custom<Foo>($foo)` will in the parser and printer
 respectively generate calls to:
 
 ```c++
-LogicalResult parseFoo(AsmParser &parser, int &foo);
+ParseResult parseFoo(AsmParser &parser, int &foo);
 void printFoo(AsmPrinter &printer, int foo);
 ```
 
@@ -907,7 +907,7 @@ let assemblyFormat = "custom<Fizz>($foobar)";
 It will generate calls expecting the following signature for `parseFizz`:
 
 ```c++
-LogicalResult parseFizz(AsmParser &parser, FailureOr<NotDefaultConstructible> &foobar);
+ParseResult parseFizz(AsmParser &parser, FailureOr<NotDefaultConstructible> &foobar);
 ```
 
 A previously bound variable can be passed as a parameter to a `custom` directive
@@ -916,7 +916,7 @@ the first directive. The second directive references it and expects the
 following printer and parser signatures:
 
 ```c++
-LogicalResult parseBar(AsmParser &parser, int &bar, int foo);
+ParseResult parseBar(AsmParser &parser, int &bar, int foo);
 void printBar(AsmPrinter &printer, int bar, int foo);
 ```
 
@@ -925,7 +925,7 @@ is that the parameter for the parser must use the storage type of the parameter.
 For example, `StringRefParameter` expects the parser and printer signatures as:
 
 ```c++
-LogicalResult parseStringParam(AsmParser &parser, std::string &value);
+ParseResult parseStringParam(AsmParser &parser, std::string &value);
 void printStringParam(AsmPrinter &printer, StringRef value);
 ```
 

mlir/docs/PatternRewriter.md

@@ -464,7 +464,7 @@ Passes that utilize rewrite patterns should aim to provide a common set of
 options and toggles to simplify the debugging experience when switching between
 different passes/projects/etc. To aid in this endeavor, MLIR provides a common
 set of utilities that can be easily included when defining a custom pass. These
-are defined in `mlir/RewritePassUtil.td`; an example usage is shown below:
+are defined in `mlir/Rewrite/PassUtil.td`; an example usage is shown below:
 
 ```tablegen
 def MyRewritePass : Pass<"..."> {

mlir/docs/SymbolsAndSymbolTables.md

@@ -21,14 +21,14 @@ into the system.
 The `Symbol` infrastructure essentially provides a non-SSA mechanism in which to
 refer to an operation symbolically with a name. This allows for referring to
 operations defined above regions that were defined as `IsolatedFromAbove` in a
-safe way. It also allows for symbolically referencing operations define below
+safe way. It also allows for symbolically referencing operations defined below
 other regions as well.
 
 ## Symbol
 
 A `Symbol` is a named operation that resides immediately within a region that
 defines a [`SymbolTable`](#symbol-table). The name of a symbol *must* be unique
-within the parent `SymbolTable`. This name is semantically similarly to an SSA
+within the parent `SymbolTable`. This name is semantically similar to an SSA
 result value, and may be referred to by other operations to provide a symbolic
 link, or use, to the symbol. An example of a `Symbol` operation is
 [`func.func`](Dialects/Builtin.md/#func-mlirfuncop). `func.func` defines a
@@ -125,7 +125,7 @@ Using an attribute, as opposed to an SSA value, has several benefits:
 
     -   If we were to use SSA values, we would need to create some mechanism in
         which to opt-out of certain properties of it such as dominance.
-        Attributes allow for referencing the operations irregardless of the
+        Attributes allow for referencing the operations regardless of the
         order in which they were defined.
     -   Attributes simplify referencing operations within nested symbol tables,
         which are traditionally not visible outside of the parent region.

mlir/include/mlir/IR/DialectImplementation.h

@@ -89,7 +89,7 @@ struct FieldParser<
   }
 };
 
-/// Parse an attribute.
+/// Parse a type.
 template <typename TypeT>
 struct FieldParser<
     TypeT, std::enable_if_t<std::is_base_of<Type, TypeT>::value, TypeT>> {

mlir/include/mlir/IR/OpBase.td

@@ -401,7 +401,7 @@ class Op<Dialect dialect, string mnemonic, list<Trait> props = []> {
   // an additional `LogicalResult verify()` declaration will be generated on the
   // operation class. The operation should implement this method and verify the
   // additional necessary invariants. This verifier shouldn't access any nested
-  // operations because those operations may ill-formed. Use the
+  // operations because those operations may be ill-formed. Use the
   // `hasRegionVerifier` below instead.
   bit hasVerifier = 0;
 

mlir/include/mlir/Tools/mlir-opt/MlirOptMain.h

@@ -325,7 +325,7 @@ LogicalResult MlirOptMain(int argc, char **argv, llvm::StringRef toolName,
                           DialectRegistry &registry);
 
 /// Implementation for tools like `mlir-opt`.
-/// This function can be used with registrationAndParseCLIOptions so that
+/// This function can be used with registerAndParseCLIOptions so that
 /// CLI options can be accessed before running MlirOptMain.
 /// - inputFilename is the name of the input mlir file.
 /// - outputFilename is the name of the output file.