Open Xuanwo opened 8 months ago
Trying to build OpenDAL
seems like an interesting test.
It is quite complex, but it is also a potential real use case (since there seem to be no C# bindings for it project).
Looking at the log reveals some interesting things.
Currently, there are 2244 codegen panics in the build log. A large chunk of them (573, ~25%) are related to calling/creating function pointers. Another large group are the errors related to DSTs (995, ~44%).
Those 2 groups total in 1568 panics(70%). Other issues cause much fewer errors, 676(~30%).
While I am almost certain there are other issues which are not currently picked up, this suggests that a lot of progress can be made by focusing on those areas.
The issue with ReifyFnPointer
was also present when building core
, so I fixed it.
d2d4ca1 allows creation of function pointers (but functions with alternative calling conventions / marked with the #[track_caller] attribute don't work properly yet).
5946c83 adds the ability to call those function pointers.
There are some function pointer related things that still need some consideration.
For example, distinguishing between managed and unmanged function pointers has huge performance benefits, but could potentially introduce runtime issues if not done right.
But even with those minor issues unresolved, calling/creating function pointers should work now, reducing the amount of codegen panics.
Those also cause trouble in core
, so they were going to be fixed anyaway
DSTs are a bit more tricky, since they require revamping some of the code handling fat pointers. The newest set of patches greatly improves support for DSTs, and a large chunk of them should now work, but there are still some issues.
Due to Ty::is_sized
sometimes panicking, the codegen is currently using is_trivialy_sized
. This may lead it to assume a type is a DST when it is not. Once I figure out the cause of the issue with is_sized
, this should be working properly.
Getting the address of a dynamically sized field of a DST currently should copy the address and metadata of the field, but this currently does not happen, creating fat pointers with garbage addresses/metadata, causing runtime issues.
Once those issues get resolved, a large chunk of errors should disappear. Admittedly, those are probably the low-hanging fruit, but this should be a good step forward.
This is a small clarification about where the project is headed.
Also, I would not say that the project will be close to being mature when it is capable of properly building OpenDAL. I believe it would be ready to be used at that stage, but there are some other things I would like to do before it is "mature" to me.
Mainly:
Fuzzing the codegen using rustlatis. This would catch most codegen bugs and miscompilations, allowing the project to be used with confidence in its output.
Not relying on ILASM. While ilasm is great for development, it increases compile times and requires users to install additional dependencies. Dropping it would probably be a requirement for the project to become a part of the Rust compiler.
General fix ups/ refactoring, removing all transmute
calls. Most of those things are fine in development, but will should be fixed to allow easier maintenance in the future. The codegen should not rely on implementation details to work.
Getting an official target triple from the Rust team - this would allow crates to make .NET specific accommodations/fixes. It is required to get some low-level crates to work.
Stable interop APIs
.NET
specific fixes to the standard library. Currently, the codegen works by pretending that the compiled executable is running on a Linux machine. Things like standard output are emulated. By using .NET APIs directly, much greater compatibility and performance can be achieved.
Run crater
- crater
is an internal Rust tool used to check if/how many crates are impacted by a change to the compiler. Ideally, I would like a large part of the Rust ecosystem to work out of the box.
Minor management-related things. A proper code of conduct, CONTRIBUTING.md
, bug report forms - things the project will need if it is used by a larger amount of people.
I know those are just nitpicky semantics (and I hope I don't come off as rude), but I am rather cautious when it comes to those things.
I would like the project to be in a near-prefect state before calling it mature.
I don't want to claim the project is more ready than it is - I would not want someone to assume it is fully working, only to surprise them with hidden issues.
NOTE: This test report is for informational purposes only and does not suggest any immediate need for repair.
Following the instructions at https://github.com/FractalFir/rustc_codegen_clr/issues/25, I attempted to use
rustc_codegen_clr
with opendal. OpenDAL is a REAL Rust crate that facilitates IO, networking, and asynchronous operations. If we successfully compile OpenDAL and integrate it with CLR,rustc_codegen_clr
will be nearing maturity.cargo test compile_test::opendal_test::cargo_release
Worth of mention: