Clarify/Fix parts of MLIR toy tutorial chapter 2

[matthiaskramm]

Summary

• clarify what "registering" means.
• clarify Op dereferencing
• clarify override/virtual phrasing
• omit duplication in code samples
• fix OpAsmPrinter comment

[stephenneuendorffer]

LGTM

mlir/docs/Tutorials/Toy/Ch-2.md

 
 ### Opaque API
 
 MLIR is designed to be a completely extensible system, and as such, the
 infrastructure has the capability to opaquely represent all of its core
 components: attributes, operations, types, etc. This allows MLIR to parse,
 represent, and [round-trip](../../../getting_started/Glossary.md#round-trip) any valid IR. For
 example, we could place our Toy operation from above into an `.mlir` file and
-round-trip through *mlir-opt* without registering anything:
+round-trip through *mlir-opt* without registering any dialect:
 
 ```mlir
 func @toy_func(%tensor: tensor<2x3xf64>) -> tensor<3x2xf64> {
   %t_tensor = "toy.transpose"(%tensor) { inplace = true } : (tensor<2x3xf64>) -> tensor<3x2xf64>
   return %t_tensor : tensor<3x2xf64>
 }
 ```
 

 
 To effectively interface with MLIR, we will define a new Toy dialect. This
 dialect will properly model the semantics of the Toy language, as well as
 provide an easy avenue for high-level analysis and transformation.
 
 ```c++
 /// This is the definition of the Toy dialect. A dialect inherits from
 /// mlir::Dialect and registers custom attributes, operations, and types (in its
-/// constructor). It can also override some general behavior exposed via virtual
-/// methods, which will be demonstrated in later chapters of the tutorial.
+/// constructor). It can also override virtual methods to change some general
+/// behavior, which will be demonstrated in later chapters of the tutorial.
 class ToyDialect : public mlir::Dialect {
  public:
   explicit ToyDialect(mlir::MLIRContext *ctx);
 
   /// Provide a utility accessor to the dialect namespace. This is used by
   /// several utilities.
   static llvm::StringRef getDialectNamespace() { return "toy"; }
 };

 [TensorType](../../LangRef.md#tensor-type). An operation inherits from the
 [CRTP](https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern)
 `mlir::Op` class which also takes some optional [*traits*](../../Traits.md) to
 customize its behavior. These traits may provide additional accessors,
 verification, etc.
 
 ```c++
 class ConstantOp : public mlir::Op<ConstantOp,
-                     /// The ConstantOp takes zero inputs.
+                     /// The ConstantOp takes no inputs.
                      mlir::OpTrait::ZeroOperands,
                      /// The ConstantOp returns a single result.
                      mlir::OpTrait::OneResult,
                      /// The ConstantOp is pure and has no visible side-effects.
                      mlir::OpTrait::HasNoSideEffect> {
 
  public:
   /// Inherit the constructors from the base Op class.

 ```c++
 void processConstantOp(mlir::Operation *operation) {
   ConstantOp op = llvm::dyn_cast<ConstantOp>(operation);
 
   // This operation is not an instance of `ConstantOp`.
   if (!op)
     return;
 
-  // Get the internal operation instance back.
+  // Get the internal operation instance wrapped by the smart pointer.
   mlir::Operation *internalOperation = op.getOperation();
   assert(internalOperation == operation &&
          "these operation instances are the same");
 }
 ```
 
 ### Using the Operation Definition Specification (ODS) Framework
 

 case it will generate our first build method for us. For the rest, we define the
 [`builders`](../../OpDefinitions.md#custom-builder-methods) field. This field
 takes a list of `OpBuilder` objects that take a string corresponding to a list
 of C++ parameters, as well as an optional code block that can be used to specify
 the implementation inline.
 
 ```tablegen
 def ConstantOp : Toy_Op<"constant", [NoSideEffect]> {
-  // Provide a summary and description for this operation. This can be used to
-  // auto-generate documentation of the operations within our dialect.
-  let summary = "constant operation";
-  let description = [{
-    Constant operation turns a literal into an SSA value. The data is attached
-    to the operation as an attribute. For example:
-
-      %0 = "toy.constant"()
-         { value = dense<[[1.0, 2.0, 3.0], [4.0, 5.0, 6.0]]> : tensor<2x3xf64> }
-        : () -> tensor<2x3xf64>
-  }];
-
-  // The constant operation takes an attribute as the only input.
-  // `F64ElementsAttr` corresponds to a 64-bit floating-point ElementsAttr.
-  let arguments = (ins F64ElementsAttr:$value);
-
-  // The generic call operation returns a single value of TensorType.
-  // F64Tensor corresponds to a 64-bit floating-point TensorType.
-  let results = (outs F64Tensor);
-
-  // Add additional verification logic to the constant operation. Here we invoke
-  // a static `verify` method in a c++ source file. This codeblock is executed
-  // inside of ConstantOp::verify, so we can use `this` to refer to the current
-  // operation instance.
-  let verifier = [{ return ::verify(*this); }];
+  ...
 
   // Add custom build methods for the constant operation. These methods populate
   // the `state` that MLIR uses to create operations, i.e. these are used when
   // using `builder.create<ConstantOp>(...)`.
   let builders = [
     // Build a constant with a given constant tensor value.
     OpBuilder<"Builder *builder, OperationState &result, "
               "DenseElementsAttr value", [{

 /// The 'OpAsmPrinter' class is a stream that will allows for formatting
 /// strings, attributes, operands, types, etc.
 static void print(mlir::OpAsmPrinter &printer, PrintOp op) {
   printer << "toy.print " << op.input();
   printer.printOptionalAttrDict(op.getAttrs());
   printer << " : " << op.input().getType();
 }
 
-/// The 'OpAsmPrinter' class provides a collection of methods for parsing
+/// The 'OpAsmParser' class provides a collection of methods for parsing
 /// various punctuation, as well as attributes, operands, types, etc. Each of
 /// these methods returns a `ParseResult`. This class is a wrapper around
 /// `LogicalResult` that can be converted to a boolean `true` value on failure,
 /// or `false` on success. This allows for easily chaining together a set of
 /// parser rules. These rules are used to populate an `mlir::OperationState`
 /// similarly to the `build` methods described above.
 static mlir::ParseResult parsePrintOp(mlir::OpAsmParser &parser,
                                       mlir::OperationState &result) {