diff --git a/_posts/2024-09-20-reusing-rustc-components.md b/_posts/2024-09-20-reusing-rustc-components.md
index 3ae4420..cba82fa 100644
--- a/_posts/2024-09-20-reusing-rustc-components.md
+++ b/_posts/2024-09-20-reusing-rustc-components.md
@@ -44,7 +44,7 @@ io::_print(
 
 We could rewrite the parser from scratch, as `rustc_parse_format` is a tiny component and not terribly difficult to implement. But tweaking the build system to allow the reuse of that component, as well as writing the various Rust <-> C++ interfaces needed for interacting with the `crate`, helped pave the way for the most crucial of the components we are currently reusing - `polonius`, the next generation Rust borrow-checker, which you can read more about [here](https://rust-lang.github.io/polonius/). It can already be used on `rustc` with the nightly `-Z polonius` option. It is currently being rewritten, and not stable yet, but will eventually allow a couple more constructs which are rejected by the current borrow-checking algorithm while still being just as correct.
 
-We plan on adding more components to `rustc` in the future where _NOTE: Reword "it makes sense"_. For example, there are currently efforts towards making a new trait solver for `rustc` - if separate enough from the compiler, it could be integrated and used by `gccrs` to perform trait-solving on our internal representation. Similarly, [Jack Wrenn](https://github.com/jswrenn) gave a fantastic talk at RustConf 2024 detailling checked-transmutes _NOTE: Add links to proposals, blogpost, etc_. Talking with Jack after his talk revealed that the algorithm powering the project is quite separate from the compiler. It uses its own graph representation, which is built from `rustc`'s internal representation, but could also be built using `gccrs`'!
+We plan on adding more components to `rustc` in the future where possible. For example, there are currently efforts towards making a new trait solver for `rustc` - if separate enough from the compiler, it could be integrated and used by `gccrs` to perform trait-solving on our internal representation. Similarly, [Jack Wrenn](https://github.com/jswrenn) gave a fantastic talk at RustConf 2024 detailling [safe-transmutes](https://github.com/rust-lang/rust/issues/99571). Talking with Jack afterwards revealed that the algorithm powering the project is quite separate from the compiler. It uses its own graph representation, which is built from `rustc`'s internal representation, but could also be built using `gccrs`'!
 
 While we do want to encourage sharing between the two projects, it is not possible to reuse any component we want from `rustc` - The two compilers' internal representations are extremely different, and converting back-and-forth from one to the other would be extremely costly. A simple but really annoying example of this lies in our AST structure, namely for representing the "block" expressions used in Rust: