Attribute Macro format_op 

#[format_op]

Derive Printable and Parsable for Ops

Note: It is suggested to use the pliron_op macro instead of using this macro directly. The documention here is useful though, because pliron_op’s format field expands to this macro.

This derive only supports a syntax in which results appear before the opid: res1, ... = opid ... The format string specifies what comes after the opid.

1. A named variable $name specifies a named attribute of the operation. This cannot be combined with the attr_dict directive.

2. An unnamed variable $i specifies operands[i], except when inside some directives. This cannot be combined with the “operands” directive.

3. The “type” directive specifies that a type must be parsed. It takes one argument, which is an unnamed variable $i with i specifying result[i]. This cannot be combined with the “types” directive.

4. The “region” directive specifies that a region must be parsed. It takes one argument, which is an unnamed variable $i with i specifying region[i]. This cannot be combined with the “regions” directive.

5. The “attr” directive can be used to specify attribute on an Op when the attribute’s rust type is fixed at compile time. It takes two mandatory and two optional arguments.

   1. The first operand is a named variable $name which is used as a key into the operation’s attribute dictionary
   2. The second is the concrete rust type of the attribute. This second argument can be a named variable $name (with name being in scope) or a literal string denoting the path to a rust type (e.g. `::pliron::builtin::attributes::IntegerAttr`).
   3. Two additional optional arguments can be specified:
      • The “label” directive, with one argument, a named variable $label, which specifies the label to be used while printing / parsing the attribute.
      • The “delimiters” directive, which takes two literal arguments, specifying the opening and closing delimiters to be used while printing / parsing.

   The advantage over specifying an attribute using the attr directive (as against just using a named variable) is that the attribute-id is not a part of the syntax here (because the type is statically known, allowing us to be able to parse it), thus allowing it to be more succinct. This cannot be combined with the attr_dict directive.

6. The “succ” directive specifies an operation’s successor. It takes one argument, which is an unnamed variable $i with i specifying successor[i].

7. The “operands” directive specifies all the operands of an operation. It takes one argument which is a directive specifying the separator between operands. The following directives are supported:

   1. NewLine: takes no argument, and specifies a newline to be used as list separator.
   2. CharNewline(`c`): takes a single character argument that will be followed by a newline.
   3. Char(`c`): takes a single character argument that will be used as separator.
   4. CharSpace(`c`): takes a single character argument that will be followed by a space.

8. The “successors” directive specifies all the successors of an operation. It takes one argument which is a directive specifying the separator between successors. The separator directive is same as that for “operands” above. This cannot be combined with the “succ” directive.

9. The “regions” directive specifies all the regions of an operation. It takes one argument which is a directive specifying the separator between regions. The separator directive is same as that for “operands” above. This cannot be combined with the “region” directive.

10. The “attr_dict” directive specifies an AttributeDict. It cannot be combined with any of attr, opt_attr directives or a named variable ($name).

11. The “types” directive specifies all the result types of an operation. It takes one argument which is a directive specifying the separator between result types. The separator directive is same as that for “operands” above. This cannot be combined with the “type” directive.

12. The “opt_attr” directive specifies an optional attribute on an Op. It takes two or more arguments, which are same as those of the attr directive. This cannot be combined with the attr_dict directive.

Examples:

1. Derive for a struct, with no format string (default format):

use pliron::derive::{def_op, format_op, verify_succ};
#[verify_succ]
#[format_op]
#[def_op("test.myop")]
struct MyOp;

2. An example with a custom format string:

use pliron::derive::{def_op, derive_op_interface_impl, format_op, verify_succ};
use pliron::{op::Op, builtin::op_interfaces::
    {OneOpdInterface, OneResultInterface, NOpdsInterface, NResultsInterface}};
#[verify_succ]
#[format_op("$0 `<` $attr `>` `:` type($0)")]
#[def_op("test.one_result_one_operand")]
#[derive_op_interface_impl
    (OneOpdInterface, OneResultInterface, NOpdsInterface<1>, NResultsInterface<1>)]
struct OneResultOneOperandOp;

More examples can be seen in the tests for this macro in pliron-derive/tests/format_op.rs.