Problem
The generator now supports projecting selected MLIR interfaces into member-bearing partial C# interfaces via MLIR.NET overlay metadata. However, the generated C# surface currently loses a lot of useful explanatory context:
- upstream
Interface records often carry a description;
- upstream
InterfaceMethod records often carry method descriptions;
- mapped C# properties and methods currently expose only names and types, without generated XML documentation that explains what they mean.
This makes the generated interface API harder to discover and use, especially for interfaces such as ShapedTypeInterface where the projected C# members are meant to feel like a real user-facing contract rather than just marker metadata.
Proposed Change
Extend the importer and generator so projected C# interfaces and their mapped members carry XML documentation derived from upstream MLIR interface metadata and MLIR.NET overlay metadata.
Specifically:
- preserve interface-level documentation for generated partial C# interfaces;
- preserve upstream method descriptions for mapped C# members when available;
- allow MLIR.NET overlays to override or supplement generated member docs when the projected C# surface differs meaningfully from the upstream C++ wording;
- emit XML doc comments for generated property- and method-shaped members.
Suggested Model/Schema Work
A reasonable first step would be:
- continue using upstream
Interface.description as the default interface summary/remarks source;
- use upstream
InterfaceMethod.description as the default member summary source;
- add optional overlay fields for C#-specific documentation when needed, for example:
csharpSummary
csharpDescription
- or member-level equivalents on
MLIRNet_InterfaceProperty / future MLIRNet_InterfaceMethod
Exact field names can vary, but the generator should support both:
- sensible defaults from upstream metadata;
- explicit MLIR.NET wording when the projected C# API needs different phrasing.
Design Principles
- Prefer upstream MLIR documentation as the default source of truth.
- Let MLIR.NET overlays refine wording when the projected C# contract differs from the original C++ surface.
- Keep documentation generation generic and metadata-driven.
- Preserve existing XML doc generation style used elsewhere in the repo.
- Do not require every mapped member to supply custom documentation.
Out Of Scope
- Documentation generation for operation interfaces unless it falls out naturally from the same mechanism.
- Rewriting or normalizing all upstream prose into idiomatic C# docs in the first pass.
- Runtime behavior changes.
Acceptance Criteria
- Generated projected interfaces emit XML documentation when interface metadata is available.
- Generated mapped properties emit XML documentation derived from upstream method metadata when available.
- If method-shaped interface mappings exist, generated mapped methods also emit XML documentation.
- Overlay metadata can override or supplement generated docs for at least one interface/member.
- Add importer and generator tests proving:
- interface docs are preserved;
- mapped member docs are preserved;
- overlay docs can override defaults;
- marker-only interfaces still behave correctly.
Problem
The generator now supports projecting selected MLIR interfaces into member-bearing partial C# interfaces via MLIR.NET overlay metadata. However, the generated C# surface currently loses a lot of useful explanatory context:
Interfacerecords often carry adescription;InterfaceMethodrecords often carry method descriptions;This makes the generated interface API harder to discover and use, especially for interfaces such as
ShapedTypeInterfacewhere the projected C# members are meant to feel like a real user-facing contract rather than just marker metadata.Proposed Change
Extend the importer and generator so projected C# interfaces and their mapped members carry XML documentation derived from upstream MLIR interface metadata and MLIR.NET overlay metadata.
Specifically:
Suggested Model/Schema Work
A reasonable first step would be:
Interface.descriptionas the default interface summary/remarks source;InterfaceMethod.descriptionas the default member summary source;csharpSummarycsharpDescriptionMLIRNet_InterfaceProperty/ futureMLIRNet_InterfaceMethodExact field names can vary, but the generator should support both:
Design Principles
Out Of Scope
Acceptance Criteria