Over the past few years, Ferrous Systems has been developing Ferrocene, a distribution of the Rust compiler for safety-critical (qualified for ISO 26262 and IEC 61508) and security.

Being a downstream of the Rust project, Ferrocene doesn't exist in a bubble, as we constantly import new features, enhancements, and bug fixes merged into Rust. From the start, one of our goals was establishing a symbiotic relationship with the upstream Rust project: while we benefit from Rust's improvements, the Rust project and its wider communities should also benefit from the work we do on Ferrocene.

Parallel CI infrastructure

Ferrocene maintains its own CI infrastructure, which indirectly runs tests for all changes merged in the rust-lang/rust repository, as we run automatic imports daily. This CI infrastructure doesn't reuse any configuration from upstream, and instead has been developed from scratch to better support our qualification efforts.

In our CI, we run a slightly different configuration than what upstream does: some compiler configuration flags are different, and we run the tests on other OS versions. Occasionally, that leads us to discover issues not caught by upstream, and we immediately open issues or send PRs addressing the problem, like for a recent regression in the build system.

This doesn't mean upstream CI is not adequate: the CI infrastructure maintained by the Rust Infrastructure Team is well built and thorough (we have full confidence in its outcomes), and we have an open collaboration with them on the build system and CI. It's just impossible for a single CI to cover the combinatory explosion of options to test. Having multiple independent, parallel, rock solid CI pipelines can only benefit Rust.

Contributing changes upstream

In addition to importing the changes merged upstream, we also need to change Ferrocene to better support our workflows, targets, and customers. When we do, we always propose the change upstream to give back to the wider Rust community.

We're proud to say that after two years of development and being on the finishing line of obtaining the qualification of Ferrocene from the assessors, the difference between Rust and Ferrocene in the compiler/ and library/ source code directories only amounts to support for the LynxOS-178 target and the temporary implementation of a feature we proposed and we'll implement upstream.

Of course there are other changes in the rest of the codebase and test suite to support our qualification efforts, but one of the Ferrocene pillars is that the standard library and the compiler must not diverge from upstream. We managed to do so for the past two years, and we'll continue on this path for the years to come.

As an example, here is a subset of the changes we upstreamed:

• We added structured output to the Rust build system, to record which steps and tests were executed (#93717, #108659, #111936)

• We made it easier to hook a custom libc into a new build of Rust when porting to a new target (libc#3037, #108898)

• We changed the Rust compiletest suite to produce an error if an ignore directive is invalid, which helped discover accidentally ignored tests (#108905, #110319)

• We changed Rust's own test suite to successfully run on targets without unwinding (#111992, #112314, #112418, #112454)

Looking forward

The Decade of Rust event on October 4th is approaching fast, so be sure to register and tune in to learn about the future of Ferrocene! You can also look forward to more blog posts as we get closer to the event, where we share more of our approach and plans.

Pre-release builds of Ferrocene 23.06 can be requested if you're interested to check out Ferrocene: you can reach us through our contact form to learn more.