pavex VS rustc_codegen_clr

The update goes into the details of the rationale driving the new design choices, which might of interest if you use or design web frameworks. The project is developed in the open on GitHub if you want to have a look under the hood.

The code is also available on GitHub if you want to have a look.

After adding support for statics and many bug fixes related to pointers/slices, my compiler backend targeting .NET can finally build a barely working version of the standard library. It can be loaded into the .NET runtime, allocate memory (e.g. for a Box, Vec or String), push elements to Vec's and String's (currently without relocations). There are also some other parts of the standard library that already work, but I want to stress that the project is still fairly early into development (I started working on it late August), and you should expect most things in std to not work at all. Things working is the exception, not the rule. This newest set of commits allows you to use a small subset of the standard library, within code running inside the .NET runtime. | Here is some Rust code that I wrote to demo the ability to use the Rust std within the .NET runtime:

This is a small update about my rustc backend, which is supposed to allow compilation of Rust code into .NET assemblies. This would allow you to use Rust crates in C#, and C# libraries in Rust.

I am currently working on a rust codegen targeting .NET. One of the features I currently work on is a .NET interop layer, mycorrhiza, and I am having some trouble modeling certain type constraints. There are 2 ways to store a reference to a GC type in Rust: 1. By a handle - this type has some cost associated with it, but can be stored anywhere (heap, stack). 2. By a raw reference - raw references may only live on the stack. They can be copied, and behave almost exactly like a normal rust type (with exceptions related to transmutes and enums), as long as they are stored on the stack.