This is explicitly a non-goal. Ferrocene considers itself a certified downstream of the rust project and as such we certified the rust compiler as it was at 1.68. There's no effort or push to standardize the language from our side.
As part of the certification efforts, we had to write a spec since some description of the language is required. But this spec is a descriptive spec, describing the intended behavior of the language at that point in time - it's mostly distilled from other forms of documenting rustcs behavior, such as the RFCs etc. If there's a divergence between the spec and the compiler, we'll need to investigate whether we uncovered a bug in the spec or in the compiler.
It's not a complete spec, nor does it intend to be. The format it's written is is useful for the certification and documentation effort, but it doesn't cover large chunks that you'd for example need to write second rust compiler implementation. The spec is likely usefor for others, but its Raison d'Être is to serve as a basis for the certification and as such, it will remain limited in scope.
Is there any high-level description of the downstream changes in ferrocene and a roadmap of which changes could be upstreamed and which would probably "never" be acceptable upstream?
> Is there any high-level description of the downstream changes in ferrocene:
The list of relevant changes to the compiler is the empty set. We wanted to certify the compiler without forking it or restricting the supported language features.
We do build and test some targets to a higher tier level than upstream rust and do have support for custom proprietary targets which the rust project will never support (1), but that makes for a tiny change set. (Measured in literally tens of lines).
Most of Ferrocene is the LTS support and the qualification documentation, both of which upstream has no interest in providing. The documentation also describes our QA process and unless you’ll adopt our procedures, you’ll have to adjust the documentation and then re-certify.
(1) to a large extend because the rust project cannot sign an NDA and support proprietary hardware in its CI.
As part of the certification efforts, we had to write a spec since some description of the language is required. But this spec is a descriptive spec, describing the intended behavior of the language at that point in time - it's mostly distilled from other forms of documenting rustcs behavior, such as the RFCs etc. If there's a divergence between the spec and the compiler, we'll need to investigate whether we uncovered a bug in the spec or in the compiler.
It's not a complete spec, nor does it intend to be. The format it's written is is useful for the certification and documentation effort, but it doesn't cover large chunks that you'd for example need to write second rust compiler implementation. The spec is likely usefor for others, but its Raison d'Être is to serve as a basis for the certification and as such, it will remain limited in scope.