[bug]edsl InOut&Input anno F722 error

[starrryz]

Describe the bug

1. The Problem The current DSL design uses InOut["memref<?xf32, 3>"] to define kernel signature types. While this works at runtime (via class_getitem), flake8 treats the string inside the brackets as a forward reference type and attempts to parse it. Since MLIR syntax includes characters like < and ?, flake8 fails to parse them as valid Python code, resulting in F722: syntax error in forward annotation.

2. Temporary Solution We are currently suppressing this error using inline comments: # noqa: F722. However, this is not a long-term solution as it bypasses static checks.

3. Attempted Solutions & Roadblocks

We explored several approaches to resolve this natively without suppression, but each faced significant blockers:

Attempt A: Change to Function Call Syntax (InOut(...))

Approach: Convert InOut from a class to a factory function to pass the string as a standard argument.

Result: Failed.

Reason: The backend compiler (codegen.py) relies on analyzing the Abstract Syntax Tree (AST). It strictly expects ast.Subscript nodes (brackets []). Changing to ast.Call nodes (parentheses ()) caused the compiler to crash (AttributeError: 'Call' object has no attribute 'value'). Rewriting the AST visitor logic in the backend was deemed too risky/invasive.

Attempt B: Use Standard typing.Literal

Approach: Use InOut[Literal["..."]].

Result: Rejected.

Reason: While this satisfies flake8, it makes the kernel signature extremely verbose and hard to read, harming the DSL's usability.

Attempt C: Use Aliased Literal (L = Literal)

Approach: Define L = Literal to keep code concise (InOut[L["..."]]).

Result: Failed.

Reason: flake8's static analysis is rigid. It does not resolve aliases for F722 checks. It still sees the brackets and attempts to parse the content, persisting the F722 error.

Attempt D: Double Quoting / Nested Strings (InOut["'...'"])

Approach: Wrap the content in extra quotes so flake8 sees a valid Python string literal.

Result: Failed.

Reason: flake8 behavior proved inconsistent/stubborn regarding nested quotes in annotations. Additionally, this requires modifying the codegen backend to strip the extra quotes, adding unnecessary complexity for an uncertain fix.

4. Conclusion Due to the limitations of flake8's F722 check and the rigidity of the current AST-based backend compiler, we have documented these attempts to prevent redundant future investigations.

Environment details

triton_v3.5_edsl

[sgjzfzzf]

Closed by #338.