DenseResourceElementsAttr currently models its raw resource handle as a string in the generated C# surface. That is enough to unblock codegen, but it leaves the handle semantically opaque.
Desired follow-up:
- introduce a semantic type for resource handles in MLIR.NET
- teach the builtin prelude overlay to use that type for DenseResourceElementsAttr
- keep parse/print behavior aligned with MLIR's resource-handle assembly syntax
- add tests that verify generated code uses the richer type instead of string
This should stay in the earliest layer that can express the concept cleanly; if the current syntax/runtime model is missing a suitable abstraction, add it there rather than patching the generator.
DenseResourceElementsAttr currently models its raw resource handle as a string in the generated C# surface. That is enough to unblock codegen, but it leaves the handle semantically opaque.
Desired follow-up:
This should stay in the earliest layer that can express the concept cleanly; if the current syntax/runtime model is missing a suitable abstraction, add it there rather than patching the generator.