HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
thepowersgang
mrustc
C++2016–2026
thepowersgang / mrustc

mrustc

Alternative rust compiler (re-implementation)

72Distinct people
90Mentions
0Explicit recommenders
2.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Alternative rust compiler (re-implementation)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year90 dated mentions

Observed mentions: 2016-08-10 14:01:56 UTC to 2026-10-14 23:33:51 UTC.

0510152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 9 mentions; 2 submissions, 7 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 15 mentions; 0 submissions, 15 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 15 mentions; 2 submissions, 13 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 12 mentions; 2 submissions, 10 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC514
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC927
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC606
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC15015
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC15213
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC12210
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC505
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC918

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Mutabah's Rust Compiler In-progress alternative rust compiler. Capable of building a fully-working copy of rustc, but not suitable for everyday use (due to terrible error messages). Intro This project is a "simple" rust compiler written in C++ that is able to bootstrap a "recent" rustc. As mrustc's primary goal is bootstrapping rustc, and as such it tends to assume that the code it's compiling is valid (and any errors in the generated code are mrustc bugs). Code generation is done by emitting a high-level assembly (currently very ugly C, but LLVM/cretone/GIMPLE/... could work) and getting an external tool (i.e. gcc) to do the heavy-lifting of optimising and machine code generation. Progress Builds working copies of rustc and cargo from a release source tarball Currently tested to fully bootstrap (with a binary-equal 1.91.1) version 1.90.0 Also supports and might still bootstrap (assuming the right environment) - rustc 1.19.0, 1.29.0, 1.39.0, 1.54.0, 1.74.0 NOTE: Older versions (1.29 and older) don't build on modern systems, due to outdated openssl bindings Supported Targets (CI tested for libstd): x86-64 linux GNU (Specifically Debian/Ubuntu; should always work, fully bootstrap tested) x86-64 windows MSVC (Status: runnable executables on Windows 10, but bootstrap hasn't ever been fully tested) Secondary Targets x86-64 and arm64 macOS (incomplete) x86 windows MSVC rustc bootstrap tested and validated (1.19.0 isn't fully repeatable, but later versions are) See the script TestRustcBootstrap.sh for how this was done. Getting Started You can set the number of jobs (parallel builds) by setting the enviromment variable PARLEVEL, e.g. PARLEVEL=$(nproc) for CPU core count. This can and will break at times, as such outside of toying around, it's best to do PARLEVEL=1 or let mrustc figure it out by itself. Dependencies C++14-compatible compiler (tested with gcc 5.4 and gcc 6, and MSVC 2015) C11 compatible C compiler (for output, see above) GNU make (for the mrustc makefiles) patch (for doing minor edits to the rustc source) libz-dev (used for reducing the size of bytecode files, linux only - windows uses vcpkg to download it) curl (for downloading the rust source, linux only) cmake (at least 3.4.3, required for building llvm in rustc) pkg-config (required for finding crate build deps, i.e libssl) python3 (required for building llvm in rustc) Linux GNU and macOS make RUSTCSRC - Downloads the rustc source tarball (1.29.0 by default) make -f minicargo.mk - Builds mrustc and minicargo, then builds libstd, libtest, finally rustc and cargo make -C run_rustc - Build libstd and a "hello, world" using the above-built rustc BSD Similar to Linux, but you might need to specify the rustc default target explicitly specify the compiler use gmake to run GNU make use CC=gcc or CC=egcc if cc is clang e.g. gmake CC=gcc RUSTC_TARGET=x86_64-unknown-freebsd -f minicargo.mk Windows (Tested with VS2015) Download and extract rustc-1.29.0-src.tar.gz to the repository root (such that the rustc-1.29.0-src directory is present) NOTE: I am open to suggestions for how to automate that step Open vsproject/mrustc.sln and build minicargo Run vsproject/run_hello.cmd to build libstd and "hello, world", and run it There are other similar scripts for building cargo and rustc. Cargo works, but rustc hasn't fully been tested (building LLVM on windows has been a challenge) Building non-rustc code To build your own code with mrustc, first you need to build at least libcore (and probably the full standard library). This can be done on Linux or macOS by running make -f minicargo.mk LIBS, or on windows with build_std.cmd. Next, run minicargo -L <path_to_libstd> <crate_path> to build a cargo project. or, mrustc -L <path_to_libstd> --out-dir <output_directory> <path_to_main.rs> to directly invoke mrustc. For additional options, both programs have a --help option. Diagnosing Issues and Reporting Bugs Debugging Both the makefiles and minicargo write the compiler's stdout to a file in the output directory, e.g. when building output/libcore.hir it'll save to output/libcore.hir_dbg.txt. To get full debug output for a compilation run, set the environment variable MRUSTC_DEBUG to a : separated list of the passes you want to debug (pass names are printed in every log line). E.g. MRUSTC_DEBUG=Expand:Parse make -f minicargo.mk Bug Reports Please try to include the following when submitting a bug report: What you're trying to build Your host system version (e.g. Ubuntu 17.10) C/C++ compiler version Revision of the mrustc repo that you're running Support and Discussion For problems that don't warrant opening an issue (e.g. help in running the compiler), join the IRC channel - irc.libera.chat#mrustc Current Features Full compilation chain including HIR and MIR stages (outputting to C) MIR optimisations (to take some load off the C compiler) Optional exhaustive MIR validation (set the MRUSTC_FULL_VALIDATE environment variable) Functional cargo clone (minicargo) Includes build script support Procedural macros (custom derive) Custom target specifications See docs/target.md Plans Short-term Fix currently-failing tests (mostly in type inference) Fix all known TODOs in MIR generation (still some possible leaks) Medium-term Implement MIR borrow checker Emit C code that is (more) human readable (uses names from the original source, reduced/no gotos) Add alternate backends (e.g. LLVM IR, cretonne, ...)
Read the full README on GitHub

What Hacker News says

90 sources
> Rust is managed by the Rust Foundation This is not quite true: the Foundation handles things like receiving and distributing some payments, helping conferences, employing people for operations (crates.io), and ownership of the trademark. But Rust the language and toolchain is managed by the people doing the work https://rust-lang.org/governance/ > It’s completely possible that Rust’s compiler contains a backdoor. And nobody would know. Now this last point is highly speculative and conspiratorial, Yes. > but I’m not the only one concerned about it.4 The only way to compile Rust’s compiler is using a binary package of the previous version released by the Rust Foundation. Or using https://github.com/thepowersgang/mrustc. And it is not released by the Foundation. > Since there exists only a single fully-functional, usable implementation of
Read the rest
the Rust compiler, the Rust Foundation must be trusted. > Considering its history, owners, and track record of issues with mismanagement,5 The linked to blogpost is about a fuck up that a subset of people in the project, who were responsible for RustConf, caused. The ones with leadership position stepped down from them out of their own volition. The Foundation in particular had absolutely nothing to do with the whole fiasco. > I find it hard to trust it at all. > My suggestion is: slow down. First, the community should focus on improving the Rust language itself instead of trying to “improve” other projects by rewriting them. I propose using that energy to help the GCC Front-End for Rust project6—an alternative compiler which would alleviate the concerns for the possible presence of a backdoor. Currently, it’s in an early phase of development. Who is the OP talking to? Slow what down? Because there are people working on https://github.com/Rust-GCC/gccrs. I don't work on it, because I do what I do on my spare time and I find it more rewarding to improve the user experience of rustc itself, instead of implementing the same logic for the third time in a language I don't particularly enjoy. Others are equally disinclined to work on a C++ frontend implementation. The project certainly spends its time focused on improving the language. It is also hard to tell people in the Rust Project what to do: it is open source, it is a showupocracy. The people working on it are already at their limit on what responsibilities they can take on. If the target audience of the blogpost is "the community", I also think it misses the mark. The "X rewritten in Rust" announcements I would see before LLMs would be the projects' own maintainers desiring to use Rust, and not external sources imposing it on others. There have been over enthusiastic people (and trolls) bothering projects in issue trackers and mailing lists, but I've never seen a level of volume commensurate to the meme's fame. (Nowadays I see vibe-coded projects done in Rust, but those are also not imposing their codebase on other existing projects beyond sucking up the air out of the room and making it annoying to read news aggregators due to high volume and low quality). > And the people associated with Rust often don’t seem to have the best intentions in mind, or are just following a trend without thinking for themselves. That's quite a view you have of people like myself and my colleagues. I have significant disagreements on how some facts and opinions are framed in the blogpost, but closing with stating that I and my colleagues in the project are ill intentioned and/or don't think for ourselves absolutely ensures that I won't be listening to anything else you have to say in the matter. Back when Twitter was a thing I'd spend time searching for "negative Rust sentiment" because it was an excellent way of finding unpublished feature requests and real issues that needed to be addressed, after sieving through the less than productive way those real problems were presented with. This latter emotional labor was also the reason that it caused a round of burn out, until I realized that if something is A Problem, more than one person will ultimately hit it. Which means that if there are two people raising the same point, you don't need to waste your time engaging with the one being an asshole, and instead spend your time engaging with the one that will be productive.
In Problems with the Rust Language
You could use https://github.com/thepowersgang/mrustc to get relatively modern Rust compiler (1.90 currently apparently, but every now and then that is updated). Then build newer rustc from there to reach the current 1.99. But I don't get why some people are obsessed with bootstrapping. Yes it is good to be able to do it, but it isn't something you need to do regularly. Especially since rust had a much better cross compilation story than C or C++ (not as good as go or zig though), so you don't need to bootstrap on a new architecture, just cross compile to it. Furthermore, new architectures for hosting a compiler (as opposed to just a target, like microcontrollers) is a rare event. Just something that happens every few years.
In Mold Linker Version 3.0.0 Release – Rewritten in Rust
> For the past 3 years, I have been working on compiling Rust to C. .. This is, by my count, the 14th attempt: cilly Gotta respect the dedication to a niche interest. > The primary goal of this is support for old/obscure hardware with no LLVM/GCC support. I remember reading about the bootstrapping question, how it typically requires a Rust compiler to build the Rust compiler from source. https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specif... Oh, but I see there's a C++ implementation of the Rust compiler. https://github.com/thepowersgang/mrustc Anyway, this part sounds useful too, that crustc can compile across network and devices. > You build a small C server on your Blorbo OS, run rustc on some normal platform like Linux, and let cilly talk over the wire.
In crustc: entirety of `rustc`, translated to C
> In general, the bootstrap relies on a binary package of the previous version. This is unacceptable for an otherwise source-only, self-contained distribution like the NetBSD sources. This does not paint the full picture. Rust can be bootstrapped with mrustc, which is written in C++ https://github.com/thepowersgang/mrustc Now, mrustc supports only Rust 1.74. To build Rust 1.92, you need almost 20 builds. But this can be done from source Guix has written about bootstrapping Rust from source (they care a lot about this). Here is how it looked like in 2018 https://guix.gnu.org/nb-NO/blog/2018/bootstrapping-rust/
In Rust in the NetBSD Kernel, and other odd decisions
>tool that can translate memory-safe Rust code into memory-unsafe C code Fwiw, there're two such ongoing efforts. One[1] being an, written in C++, alternative Rust compiler that emits C (aka, in project's words, high-level assembly), the other[2] being a Rust compiler backend/plugin (as an extra goal to its initial being to compile Rust to CLR asm). Last one apparently is[3] quite modular and could be adapted for other targets too. Other options are continuing/improve GCC front-end for Rust and a recent attempt to make a Rust compiler in C[4] that compiles to QBE IR which can then be compiled with QBE/cc. [1]: https://github.com/thepowersgang/mrustc [2]: https://github.com/FractalFir/rustc_codegen_clr [3]: https://old.reddit.com/r/rust/comments/1bhajzp/ [4]: https://codeberg.org/notgull/dozer
In APT Rust requirement raises questions
> and rustc could include malicious code that isn’t obvious to an outside auditor. I believe mrustc [0] is generally considered the current defense against a trusting trust attack, and IIRC it has verified the lack of such an attack up to rustc 1.74, which is the latest version it currently supports. Presumably whenever gccrs comes online that will be yet another defensive layer. [0]: https://github.com/thepowersgang/mrustc
In Pre-PEP: Rust for CPython
> Lifetimes affect drop order and program semantics. These aren't erased - they're compiled into the code being verified. mrustc is existential proof that this statement is wrong. mrustc is a bootstrap compiler for Rust written in C++ that notably ignores lifetimes since it assumes that the code it is compiling (old rustc versions) will have correct lifetimes. And despite ignoring lifetimes, its output is bit-for-bit identical to what rustc produces, so clearly those lifetimes can't have been that important :P (More seriously, lifetimes affect program correctness, but do not affect program semantics, let alone drop order. They are definitely erased as well. Not sure how you got this so wrong). [0]: https://github.com/thepowersgang/mrustc
In A comparison of Ada and Rust, using solutions to the Advent of Code

Showing the 15 most recent of 90 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.