feat[next]: type annotations in the ITIR pretty-printed syntax

[havogt]

itir.Literal.type participates in equality but was never printed, so pparse
re-typed the lexeme from scratch and any literal whose type differs from the one
implied by its spelling came back as a different term:

pformat(im.literal("1.0", "float32"))   # '1.0' -> reparses as float64
pformat(im.literal("1", "int64"))       # '1'   -> reparses as int32

What changed:

• A literal may carry a postfix type annotation: 1.0:f32, 1:i64, True:i1. No
  space, as in named_range's KDimᵥ:. It binds at prec9, tighter than every
  operator. : was previously used only by named_range, guarded on both sides.
• The annotation takes a bare scalar name and nothing else. Admitting bracketed
  forms would make 1:i16[2] ambiguous with tuple_get, which is also
  prec8 "[" prec0 "]"; 1:i16[2] is therefore a tuple index. Only a literal may
  be annotated, not a symbol.
• Type names are LLVM/MLIR spellings: bool is i1, int32 is i32, float64
  is f64. SCALAR_TYPE_NAMES in pretty_printer is the single forward mapping
  and pretty_parser imports the derived reverse map, so respelling a type is a
  one-line edit. ts.ScalarType.__str__ is deliberately unchanged; it serves
  foast_pretty_printer and error messages.
• ScalarKind.STRING has no LLVM spelling and is excluded. The table covers
  exactly builtins.TYPE_BUILTINS, asserted in a test so the two cannot drift.
• The annotation is written only where it is needed to reconstruct the literal, so
  1, 1.0 and True print as before. implied_literal_type reads the lexeme
  back to a Python value and types it with type_translation.from_value, which is
  what the frontend applies to a constant, and the parser calls the same function
  rather than mirroring it.
• Temporary.dtype with a shape or a tuple printed but did not parse; the
  declaration rule took only TYPE_LITERAL: CNAME. It now takes a type_expr
  sub-grammar, and a tuple dtype is spelled {f64, f64}, as make_tuple already
  prints.

Breaking:

• pformat emits dtype=f64 where it emitted dtype=float64.
• pformat emits dtype={f64, f64} where it emitted dtype=tuple[float64, float64].
• pparse no longer accepts dtype=float64 or 1.0:float32. One spelling, both
  directions, deliberately not a compatibility shim.

dtype= was the only place a type reached printed output before this PR, and no
code outside these two modules asserts on pformat output.

[havogt]

Should we drop printing the type for domains? Because it's the index type which I believe we fix to 32 bit.

[Copilot]

Pull request overview

This PR updates the gt4py.next.iterator pretty-printed surface syntax so that scalar types are rendered using LLVM/MLIR-style spellings (e.g., f64, i32) and literals can carry postfix type annotations (e.g., 1:i64), improving pformat/pparse roundtripping when Literal.type differs from what the lexeme implies.

Changes:

• Extend the pretty-printer to emit LLVM/MLIR-style scalar type spellings, print typed literals, and print Temporary.dtype via a shared format_type() helper.
• Extend the pretty-parser grammar to accept typed literals (<literal>:<type>) and richer dtype= type expressions (tuple and shaped scalar forms).
• Update tests and doctest-style examples to match the new printed syntax and add new roundtrip coverage.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/gt4py/next/iterator/pretty_printer.py	Adds scalar type spelling tables and prints typed literals / Temporary.dtype using the new syntax.
src/gt4py/next/iterator/pretty_parser.py	Adds parsing for typed literals and richer dtype type expressions; aligns error behavior for invalid types.
src/gt4py/next/iterator/ir_utils/ir_makers.py	Updates doctest outputs impacted by the new pretty-printed literal/type syntax.
src/gt4py/next/iterator/ir_utils/misc.py	Updates doctest output to reflect typed literal printing.
src/gt4py/next/iterator/transforms/fuse_as_fieldop.py	Updates example pretty-printed output in docstring to include typed integer literals.
src/gt4py/next/iterator/transforms/inline_fundefs.py	Updates example pretty-printed output in docstring to include typed integer literals.
src/gt4py/next/iterator/transforms/inline_lambdas.py	Updates example pretty-printed output in docstring to include typed integer literals.
src/gt4py/next/iterator/transforms/remove_broadcast.py	Updates example pretty-printed output in docstring to include typed integer literals.
src/gt4py/next/iterator/transforms/replace_get_domain_range_with_constants.py	Updates example pretty-printed output in docstring to include typed integer literals (and wraps lines).
tests/next_tests/unit_tests/iterator_tests/test_pretty_parser.py	Adds parser tests for typed literals and compound dtype expressions; updates legacy expectations.
tests/next_tests/unit_tests/iterator_tests/test_pretty_printer.py	Adds printer tests for type annotations, type spelling coverage, and compound dtype printing.
tests/next_tests/unit_tests/iterator_tests/test_pretty_roundtrip.py	Removes literal-type xfails and adds explicit roundtrip cases for typed literals and compound dtype.
tests/next_tests/unit_tests/iterator_tests/transforms_tests/test_cse.py	Updates expected pretty-printed output to include typed integer literals.
tests/next_tests/unit_tests/iterator_tests/transforms_tests/test_inline_center_deref_lift_vars.py	Updates expected pretty-printed output to include typed float literal.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[tehrengruber]

Before I read the code here: I would rather skip the type string in case it is not needed (following the same logic as type_translation.from_value). Booleans are certainly nicer as True and False not 1:f1 for our purposes.

[havogt]

For bool I had already done it and I was considering it also for domain, but for plain literals I am not so sure. It's done as discussed: only use types when they disagree with the defaults.

[havogt]

fyi, bool is still used for the dtype of temporaries. I was wondering if we should use bool here instead of i1, because it's the least intuitive, but then I thought it doesn't harm to learn this convention instead of mixing styles.

[egparedes]

Another alternative could be to use Numpy dtype abbreviations, where boolean would be b1 and the rest very similar (although the number would indicate number of bytes, not bits) : https://readmedium.com/numpy-typecodes-cheatsheet-1c4cd8fd2318

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/gt4py/next/iterator/pretty_parser.py:147

• type_expr allows shaped scalar types like f64[3], but the grammar/transformer currently accepts negative extents (because INT_LITERAL is SIGNED_INT and shaped_scalar_type does not validate). This would allow invalid dtypes such as f64[-1] to parse successfully and propagate downstream.

    def shaped_scalar_type(self, type_: ts.ScalarType, *shape: ir.Literal) -> ts.ScalarType:
        return ts.ScalarType(kind=type_.kind, shape=[int(s.value) for s in shape])

[egparedes]

Only minor code style nitpicks and questions.

[egparedes]

Direct symbol imports are forbidden in our coding conventions (Google Python Conventions)

[egparedes]

Minor coding style nitpick:

Suggested change

	if (kind := SCALAR_TYPE_KINDS.get(value.value)) is not None:
	return ts.ScalarType(kind=kind)
	raise ValueError(
	f"Invalid type '{value}'; expected one of {', '.join(sorted(SCALAR_TYPE_KINDS))}."
	)
	if (kind := SCALAR_TYPE_KINDS.get(value.value)) is None:
	raise ValueError(
	f"Invalid type '{value}'; expected one of {', '.join(sorted(SCALAR_TYPE_KINDS))}."
	)
	return ts.ScalarType(kind=kind)

[egparedes]

Another alternative could be to use Numpy dtype abbreviations, where boolean would be b1 and the rest very similar (although the number would indicate number of bytes, not bits) : https://readmedium.com/numpy-typecodes-cheatsheet-1c4cd8fd2318

[egparedes]

Optional style suggestion:

Suggested change

	if implied_literal_type(node.value) == node.type:
	return [str(node.value)]
	return [f"{node.value}:{format_type(node.type)}"]
	return [
	f"{node.value}
	if implied_literal_type(node.value) == node.type
	else f"{node.value}:{format_type(node.type)}"
	]

[egparedes]

Question: why is this case allowed? When is it normal behavior to return None?