Syncing Rust GCC backend or how to test Murphy's law

This blog post discusses the Rust GCC backend and the challenges faced when trying to sync its repository with the main Rust repository. The Rust GCC backend is a code generator backend of the Rust compiler, located in its own repository (https://github.com/rust-lang/rustc_codegen_gcc/). It allows developers to experiment without affecting Rust's CI.

The source code for this backend is also present in the Rust compiler repository (https://github.com/rust-lang/rust/tree/main/compiler/rustc_codegen_gcc). However, when the compiler adds new features, changes are needed in the codegen for different backends like LLVM, Cranelift, and GCC. This leads to unique changes in both repositories, requiring synchronization.

To merge changes between these repositories, the git subtree feature is used. This process involves cloning the repository, checking out a specific branch, building the patched git version, and having it locally. The Rust repository changes are then merged into the GCC backend, and vice versa. The backend targets a specific GCC version of the developer's own fork that includes changes not yet merged into the upstream GCC.

The author recounts their experience with syncing the Rust and GCC repositories, mentioning issues like license problems, CI mirroring issues, and CI failures due to missing dependencies like newer versions of the make and GCC features. After resolving these issues, they proceed to syncing the Rust repository changes back into the rustc_codegen_gcc repository.

However, they encounter further challenges, such as a bug in the CI caching system and a GCC build issue caused by a change in Rust's bootstrap process that affected GCC's library lookup. These issues are addressed, but new ones arise, such as a miri build failure. Eventually, the sync issues are fixed, but it took several months and multiple attempts to achieve a successful synchronization.