Update posts/2024-10-02-gccrs-an-alternative-compiler-for-rust.md

Co-authored-by: Josh Triplett <[email protected]>

Author: CohenArthur

posts/2024-10-02-gccrs-an-alternative-compiler-for-rust.md

@@ -51,8 +51,8 @@ Until the compiler can compile correct Rust and, most importantly, reject incorr
 
 In a similar vein, `gccrs` separates itself from the rest of the GCC project by not using a mailing list as its main mode of communication. The compiler we are building will be used by the Rust community, and we believe we should make it easy for that community to get in touch with us and report the problems they encounter. Since Rustaceans are used to GitHub, this is also the development platform we have been using for the past five years. Similarly, we use a [Zulip instance](https://gcc-rust.zulipchat.com/) as our main communication platform, and encourage anyone wanting to chat with us to join it. Note that we still have a mailing list, as well as an IRC channel ([email protected] and #gccrust on [oftc.net](https://oftc.net)), where all are welcome.
 
-To further ensure that gccrs does not create friction in the ecosystem, we want to be extremely careful about the finer details of the compiler, which to us means reusing `rustc` components where possible, sharing effort on those components, and communicating extensively with Rust experts in the community. Two Rust components are already in use by `gccrs`: a slightly older version of `polonius`, the next-generation Rust borrow-checker, and the [`rustc_parse_format`](https://github.com/rust-lang/rust/tree/master/compiler/rustc_parse_format) crate of the compiler. There are multiple reasons for reusing these crates, with the main one being correctness. Borrow checking is a complex topic and a pillar of the Rust programming language. Having subtle differences between `rustc` and `gccrs` regarding the borrow rules would be annoying and unproductive to users - but by making an effort to start integrating `polonius` to our compilation pipeline, we help ensure that the results we produce will be equivalent to `rustc`. You can read more about the various components we use, and we plan to reuse even more [here](https://rust-gcc.github.io/2024/09/20/reusing-rustc-components.html). We would also like to contribute to the `polonius` project itself and help make it better if possible. This cross-pollination of components will obviously benefit us, but we believe it will also be useful for the Rust project and ecosystem as a whole, and will help strengthen these implementations.
+To further ensure that gccrs does not create friction in the ecosystem, we want to be extremely careful about the finer details of the compiler, which to us means reusing `rustc` components where possible, sharing effort on those components, and communicating extensively with Rust experts in the community. Two Rust components are already in use by `gccrs`: a slightly older version of `polonius`, the next-generation Rust borrow-checker, and the [`rustc_parse_format`](https://github.com/rust-lang/rust/tree/master/compiler/rustc_parse_format) crate of the compiler. There are multiple reasons for reusing these crates, with the main one being correctness. Borrow checking is a complex topic and a pillar of the Rust programming language. Having subtle differences between `rustc` and `gccrs` regarding the borrow rules would be annoying and unproductive to users - but by making an effort to start integrating `polonius` into our compilation pipeline, we help ensure that the results we produce will be equivalent to `rustc`. You can read more about the various components we use, and we plan to reuse even more [here](https://rust-gcc.github.io/2024/09/20/reusing-rustc-components.html). We would also like to contribute to the `polonius` project itself and help make it better if possible. This cross-pollination of components will obviously benefit us, but we believe it will also be useful for the Rust project and ecosystem as a whole, and will help strengthen these implementations.
 
-Reusing `rustc` components could also be extended to other areas of the compiler: Various components of the type system, such as the trait solver, an essential and complex piece of software, could be integrated to `gccrs`. Simpler things such as parsing, as we have done for the format string parser and inline assembly parser, also make sense to us. They will help ensure that the internal representation we deal with will correspond to the one expected by the Rust standard library.
+Reusing `rustc` components could also be extended to other areas of the compiler: Various components of the type system, such as the trait solver, an essential and complex piece of software, could be integrated into `gccrs`. Simpler things such as parsing, as we have done for the format string parser and inline assembly parser, also make sense to us. They will help ensure that the internal representation we deal with will correspond to the one expected by the Rust standard library.
 
 On a final note, we believe that one of the most important steps we could take to prevent breakage within the Rust ecosystem is to further improve our relationship with the Rust community. The amount of help we have received from Rust folks is great, and we think `gccrs` can be an interesting project for a wide range of users. We would love to hear about your hopes for the project and your ideas for reducing ecosystem breakage or lowering friction with the crates you have published. We had a great time chatting about `gccrs` at RustConf 2024, and everyone's interest in the project was heartwarming. Please get in touch with us if you have any ideas on how we could further contribute to Rust.