rustc_codegen_clr
rustc_codegen_clr copied to clipboard
FractalFir
Switching to a rust-native CIL emitting API
Hi! I saw this project on reddit and was very excited; I've been trying to accomplish this exact project before and stalled multiple times due to realizing the amount of work it would require and the potential for failure. However, I was halfway through writing an ECMA-335 compliant CIL ser/de (shorthand, not serde) library on my last attempt. Would you be interested in working together to port this compiler to my own CIL backend, to hopefully achieve better efficiency and maybe even better validation? Not to mention cutting out the need to invoke ILASM or any non-rust dependencies.
If not, I'd still like to contribute to the project, and might make periodic PRs to improve it in whatever ways I see. I likely won't have a lot of time to dedicate to it any time soon, but I might be able to work on it every now and then.
That would be great!
I am currently refactoring the assembly creation to no longer depend on any particular CIL generator.
I have a AssemblyExporter trait, which handles everything related to emitting CIL.
The current API is a draft, and can be easily changed.
Currently, the API works like this:
init function initializes an exporter. It is given metadata about the assembly, such as its name.
add_struct function receives a description of a structure, and adds it to the assembly.
add_method gets the ops, locals, function name, signature, and adds it to the assembly.
finalize receives a path to file, and writes the assembly to it.
This is the minimal API required to export the assembly, and everything else can be built on top of it.
Since you have already done some work on CIL ser/de, I assume you probably know better what data you need exactly. I can open issues for add_struct and add_method, where we can discuss how exactly the API would work.
Validation is another thing I had planned, so if the exporter could also handle that, it would greatly help.
As for any timeframes - don't worry. I believe it would be unreasonable to expect anyone puts in any more work than they can and are willing to. I always appreciate any help!
Interesting. Why did you begin creating such a generic interface before you had any other impls lined up?
I knew ilasm is not the end, and was always in need of replacement. I planned to have a self-contained C# lib with C API, and use the C# APIs directly to emit the final assembly.
The idea was to keep ILASM alongside this replacement, to aid debugging. So this interface was designed more with ILASM in mind. However - anything about it can easily change. This is just a draft I spent around a day on.
I have created an issue describing what needs to be supported in order for codegen to emit all struts, unions, arrays and enums.
Nice! I originally attempted to do it by making bindings to dnLib but that required a tool to generate the bindings and I burned out trying to design that. Then I just went with implementing my own metadata editor based on the spec, and that went a lot better, I just burned out because it's a lot of repetitive, tedious work.