[mlir][doc] fix typos.

[jcai19]

Summary

Also wrap some function/class names in backticks.

[ftynse]

Thanks!

[jcai19]

In D109723#2998486, @ftynse wrote:

Thanks!

Thanks for the quick response!

mlir/docs/OpDefinitions.md

 *   The `Op` class: It is the main construct for defining operations. All facts
     regarding the operation are specified when specializing this class, with the
     help of the following constructs.
 *   The `Dialect` class: Operations belonging to one logical group are placed in
     the same dialect. The `Dialect` class contains dialect-level information.
 *   The `OpTrait` class hierarchy: They are used to specify special properties
     and constraints of the operation, including whether the operation has side
     effect or whether its output has the same shape as the input.
-*   The `ins`/`outs` marker: These are two special makers builtin to the
+*   The `ins`/`outs` marker: These are two special markers builtin to the
     `OpDefinitionsGen` backend. They lead the definitions of operands/attributes
     and results respectively.
 *   The `TypeConstraint` class hierarchy: They are used to specify the
     constraints over operands or results. A notable subclass hierarchy is
     `Type`, which stands for constraints for common C++ types.
 *   The `AttrConstraint` class hierarchy: They are used to specify the
     constraints over attributes. A notable subclass hierarchy is `Attr`, which
     stands for constraints for attributes whose values are of common types.

 
 ### Operation traits and constraints
 
 Traits are operation properties that affect syntax or semantics. MLIR C++ models
 various traits in the `mlir::OpTrait` namespace.
 
 Both operation traits, [interfaces](Interfaces.md/#utilizing-the-ods-framework),
 and constraints involving multiple operands/attributes/results are provided as
-the second template parameter to the `Op` class. They should be deriving from
+the third template parameter to the `Op` class. They should be deriving from
 the `OpTrait` class. See [Constraints](#constraints) for more information.
 
 ### Builder methods
 
 For each operation, there are a few builders automatically generated based on
 the arguments and returns types. For example, given the following op definition:
 
 ```tablegen

 ```
 
 ## Constraints
 
 Constraint is a core concept in table-driven operation definition: operation
 verification and graph operation matching are all based on satisfying
 constraints. So both the operation definition and rewrite rules specification
 significantly involve writing constraints. We have the `Constraint` class in
-[`OpBase.td`][OpBase] has the common base class for all constraints.
+[`OpBase.td`][OpBase] as the common base class for all constraints.
 
 An operation's constraint can cover different range; it may
 
 *   Only concern a single attribute (e.g. being a 32-bit integer greater than
     5),
 *   Multiple operands and results (e.g., the 1st result's shape must be the same
     as the 1st operand), or
 *   Intrinsic to the operation itself (e.g., having no side effect).

 `$_builder`, `$_op`, and `$_self`:
 
 *   `$_builder` will be replaced by a `mlir::Builder` instance so that you can
     access common build methods.
 *   `$_op` will be replaced by the current operation so that you can access
     information of the current operation.
 *   `$_self` will be replaced with the entity this predicate is attached to.
     E.g., `BoolAttr` is an attribute constraint that wraps a
-    `CPred<"$_self.isa<BoolAttr>()">`. Then for `F32:$attr`,`$_self` will be
+    `CPred<"$_self.isa<BoolAttr>()">`. Then for `F32Attr:$attr`,`$_self` will be
     replaced by `$attr`. For type constraints, it's a little bit special since
     we want the constraints on each type definition reads naturally and we want
     to attach type constraints directly to an operand/result, `$_self` will be
     replaced by the operand/result's type. E.g., for `F32` in `F32:$operand`,
-    its `$_self` will be expanded as `getOperand(...).getType()`.
+    its `$_self` will be expanded as `operand(...).getType()`.
 
 TODO: Reconsider the leading symbol for special placeholders. Eventually we want
-to allow referencing operand/result $-names; such $-names can start with
+to allow referencing operand/result `$-name`s; such `$-name`s can start with
 underscore.
 
 For example, to write an attribute `attr` is an `IntegerAttr`, in C++ you can
 just call `attr.isa<IntegerAttr>()`. The code can be wrapped in a `CPred` as
 `$_self.isa<IntegerAttr>()`, with `$_self` as the special placeholder to be
 replaced by the current attribute `attr` at expansion time.
 
 For more complicated predicates, you can wrap it in a single `CPred`, or you can

 and one is free to define dialect-specific attribute classes. ODS allows one to
 use these attributes in TableGen to define operations, potentially with more
 fine-grained constraints. For example, `StrAttr` directly maps to `StringAttr`;
 `F32Attr`/`F64Attr` requires the `FloatAttr` to additionally be of a certain
 bitwidth.
 
 ODS attributes are defined as having a storage type (corresponding to a backing
 `mlir::Attribute` that _stores_ the attribute), a return type (corresponding to
-the C++ _return_ type of the generated of the helper getters) as well as method
+the C++ _return_ type of the generated helper getters) as well as a method
 to convert between the internal storage and the helper method.
 
 ### Attribute decorators
 
 There are a few important attribute adapters/decorators/modifiers that can be
 applied to ODS attributes to specify common additional properties like
 optionality, default values, etc.:
 
llvm::Optional<MyBitEnum> symbolizeMyBitEnum(uint32_t value) {
 
   if (value & ~(1u | 2u | 4u)) return llvm::None;
   return static_cast<MyBitEnum>(value);
 }
 ```
 
 ## Type Definitions
 
-MLIR defines the TypeDef class hierarchy to enable generation of data types from
-their specifications. A type is defined by specializing the TypeDef class with
+MLIR defines the `TypeDef` class hierarchy to enable generation of data types from
+their specifications. A type is defined by specializing the `TypeDef` class with
 concrete contents for all the fields it requires. For example, an integer type
 could be defined as:
 
 ```tablegen
 // All of the types will extend this class.
 class Test_Type<string name> : TypeDef<Test_Dialect, name> { }
 
 // An alternate int type.

 ### Type documentation
 
 The `summary` and `description` fields exist and are to be used the same way as
 in Operations. Namely, the summary should be a one-liner and `description`
 should be a longer explanation.
 
 ### Type parameters
 
-The `parameters` field is a list of the types parameters. If no parameters are
+The `parameters` field is a list of the type's parameters. If no parameters are
 specified (the default), this type is considered a singleton type. Parameters
 are in the `"c++Type":$paramName` format. To use C++ types as parameters which
 need allocation in the storage constructor, there are two options:
 
 -   Set `hasCustomStorageConstructor` to generate the TypeStorage class with a
     constructor which is just declared -- no definition -- so you can write it
     yourself.
 -   Use the `TypeParameter` tablegen class instead of the "c++Type" string.

 If these autogenerated methods are not desired, such as when they conflict with
 a custom builder method, a type can set `skipDefaultBuilders` to 1 to signal
 that they should not be generated.
 
 #### Custom type builder methods
 
 The default build methods may cover a majority of the simple cases related to
 type construction, but when they cannot satisfy a type's needs, you can define
-additional convenience get methods in the `builders` field as follows:
+additional convenience 'get' methods in the `builders` field as follows:
 
 ```tablegen
 def MyType : ... {
   let parameters = (ins "int":$intParam);
 
   let builders = [
     TypeBuilder<(ins "int":$intParam)>,
     TypeBuilder<(ins CArg<"int", "0">:$intParam)>,
     TypeBuilder<(ins CArg<"int", "0">:$intParam), [{
       // Write the body of the `get` builder inline here.
       return Base::get($_ctxt, intParam);
     }]>,
     TypeBuilderWithInferredContext<(ins "Type":$typeParam), [{
       // This builder states that it can infer an MLIRContext instance from
       // its arguments.
       return Base::get(typeParam.getContext(), ...);
     }]>,
   ];
 }
 ```
 
 The `builders` field is a list of custom builders that are added to the type
-class. In this example, we provide a several different convenience builders that
+class. In this example, we provide several different convenience builders that
 are useful in different scenarios. The `ins` prefix is common to many function
 declarations in ODS, which use a TableGen [`dag`](#tablegen-syntax). What
-follows is a comma-separated list of types (quoted string or CArg) and names
+follows is a comma-separated list of types (quoted string or `CArg`) and names
 prefixed with the `$` sign. The use of `CArg` allows for providing a default
 value to that argument. Let's take a look at each of these builders individually
 
 The first builder will generate the declaration of a builder method that looks
 like:
 
 ```tablegen
   let builders = [
     TypeBuilder<(ins "int":$intParam)>,
   ];
 ```
 
 ```c++
 class MyType : /*...*/ {
   /*...*/
   static MyType get(::mlir::MLIRContext *context, int intParam);
 };
 ```
 
 This builder is identical to the one that will be automatically generated for
 `MyType`. The `context` parameter is implicitly added by the generator, and is
-used when building the file Type instance (with `Base::get`). The distinction
+used when building the Type instance (with `Base::get`). The distinction
 here is that we can provide the implementation of this `get` method. With this
 style of builder definition only the declaration is generated, the implementor
-of MyType will need to provide a definition of `MyType::get`.
+of `MyType` will need to provide a definition of `MyType::get`.
 
 The second builder will generate the declaration of a builder method that looks
 like:
 
 ```tablegen
   let builders = [
     TypeBuilder<(ins CArg<"int", "0">:$intParam)>,
   ];

 MyType MyType::get(Type typeParam) {
   // This builder states that it can infer an MLIRContext instance from its
   // arguments.
   return Base::get(typeParam.getContext(), ...);
 }
 ```
 
 In this builder example, the main difference from the third builder example
-three is that the `MLIRContext` parameter is no longer added. This is because
-the builder type used `TypeBuilderWithInferredContext` implies that the context
+there is that the `MLIRContext` parameter is no longer added. This is because
+the type builder used `TypeBuilderWithInferredContext` implies that the context
 parameter is not necessary as it can be inferred from the arguments to the
 builder.
 
 ## Debugging Tips
 
 ### Run `mlir-tblgen` to see the generated content
 
 TableGen syntax sometimes can be obscure; reading the generated content can be a

 # To see op interface documentation
 mlir-tblgen --gen-op-interface-doc -I /path/to/mlir/include /path/to/input/td/file
 ```
 
 ## Appendix
 
 ### Requirements and existing mechanisms analysis
 
-The op description should as declarative as possible to allow a wide range of
+The op description should be as declarative as possible to allow a wide range of
 tools to work with them and query methods generated from them. In particular
 this means specifying traits, constraints and shape inference information in a
 way that is easily analyzable (e.g., avoid opaque calls to C++ functions where
 possible).
 
 We considered the approaches of several contemporary systems and focused on
 requirements that were desirable: