Rust to C compiler – 95.9% test pass rate, odd platforms

todsacerdoti | 251 points

I am still waiting for any of the alternative Rust front- or backends to allow me to bootstrap Rust on alpha, hppa, m68k and sh4 which are still lacking Rust support.

Originally, the rustc_codegen_gcc project made this promise but never fulfilled it.

cbmuser | 3 days ago

this fractalfir person is super talented. See them on the rust reddit all the time. I'm not knowledgeable on compilers at all but others seem to really like their work.

cod1r | 3 days ago

"Most components of std are about 95% working in .NET, and 80% working in C."

.NET

Core tests 1662 39 12 97.02%

C

Core tests 1419 294 82.83%

Missing from HN title: The "95%" pass rate only applies to .NET. For GCC/Clang it is only "80%".

1vuio0pswjnm7 | 3 days ago

Lots of interesting use cases for this. First one that comes to mind is better interop with other languages, like Python.

iaaan | 3 days ago
[deleted]
| 3 days ago

Nim to C compiler, 100% test pass rate.

jedisct1 | 3 days ago

Is it LLVM IR --> C? Or Rust AST to C?

dilawar | 3 days ago

But does it carry the Rusty guarantees?

Krutonium | 3 days ago

Rust to C? Why would someone do that. Just write C.. if you can figure rust out you surely can figure C out and be proficient.

alexpadula | 3 days ago

Very cool. C to Rust would be fantastic.

claudiojulio | 3 days ago

At first I read it as C to rust compiler.

What is the point of compiling rust to C?

jokoon | 3 days ago

Excellent.

Now we can quickly re-rustify projects by converting them to C.

snvzz | 3 days ago

If I see something like "At least on Linux, long and long long are both 64 bits in size." my skin starts to crawl. Not only that, but GCC defines __builtin_popcount() with unsigned int / long / long long, respective, i.e. even in the text it should be mentioned correctly (unless a different compiler uses signed types there ... ugh). The call is done with unsigned, using uint64_t as a type-cast, but using a fixed __builtin_popcountl() which translates to unsigned long. There are systems where this will fail, i.e. the only safe bet to use here is __builtin_popcountll() as this will cover at least 64 bit wide arguments.

Also, if a * b overflows within the result type, it is an undefined behavior according to the C standard, so this overflow check is at least not properly portable, either, and the shown code for that is actually buggy because the last A1 has to be A0.

No idea why all that gets me so grumpy today ...

pixelfarmer | 3 days ago

[dead]

curtisszmania | 3 days ago

Why would I use a tool that doesn't pass all tests?

zwnow | 3 days ago

Would it be possible for Rust to output LLVM IR? Would that make it easier to port if they have a LLVM frontend?

nullpoint420 | 3 days ago

Of course, everyone votes up the headlines, but this link seems like premature WIP. Hopefully this will get posted for real after the presentation.

flomo | 3 days ago

I'm not convinced that it’s worth spending any time supporting most proprietary systems. Maybe not even Windows, but especially the really expensive ones.

db48x | 3 days ago

How is this not dangerous? How can one be assured that all of the compile-time safety features of the Rust compiler are still in effect? Handwaving does not help.

OutOfHere | 3 days ago