2024/11-monthly: Fix typos

Author: CohenArthur

2024/2024-11-monthly-report.org

@@ -26,13 +26,13 @@ fn handle_infallible(x: Infallible) {
 }
 #+END_SRC
 
-In that case, what should the type of ~y~ be? Since we cannot extract any information from ~x~, it doesn't really make sense to give ~y~ a regular type. Furthermore, since we cannot instantiate a value of type ~Infallible~ in the first place, it does not make sense to do pattern-matching on it to extract information! But by amaking this pattern matching resolve to the ~never~ type, we can implement traits on ~Infallible~ in order to use it just like a regular error type - since ~never~ can always coerce to any target type, as it cannot exist in the first place. This makes empty pattern matching required for handling the ~Infallible~ type and its trait implementations, which is required for handling code that can never fail. The documentation of the ~enum~ gives an interesting example, in which the ~TryFrom<T>~ trait can be implemented for ~U~ when ~U~ already implements ~From<T>~. Because we know the conversion can never fail, there is no need to expose a proper error type, as those errors will never show up.
+In that case, what should the type of ~y~ be? Since we cannot extract any information from ~x~, it doesn't really make sense to give ~y~ a regular type. Furthermore, since we cannot instantiate a value of type ~Infallible~ in the first place, it does not make sense to do pattern-matching on it to extract information! But by making this pattern matching resolve to the ~never~ type, we can implement traits on ~Infallible~ in order to use it just like a regular error type - since ~never~ can always coerce to any target type, as it cannot exist in the first place. This makes empty pattern matching required for handling the ~Infallible~ type and its trait implementations, which is required for handling code that can never fail. The documentation of the ~enum~ gives an interesting example, in which the ~TryFrom<T>~ trait can be implemented for ~U~ when ~U~ already implements ~From<T>~. Because we know the conversion can never fail, there is no need to expose a proper error type, as those errors will never show up.
 
 The fix for this is quite simple - if the ~match~ we are type-checking is empty, then we can just resolve its type to ~never~. If the match is not supposed to be empty (for example, if we are matching on an ~enum~ with one or more variants), then it's up to the exhaustiveness checker to report an issue - not the type-checker!
 
 If you are curious, you can see how this special case is handled in [[https://github.com/Rust-GCC/gccrs/blob/afbd87358cc8b4627536145510b0c17634005eb6/gcc/rust/typecheck/rust-hir-type-check-expr.cc#L1461-L1468][gccrs]] and in [[https://github.com/rust-lang/rust/blob/3d1dba830a564d1118361345d7ada47a05241f45/compiler/rustc_hir_typeck/src/_match.rs#L32-L36][rustc]].
 
-In other technical news, [[https://github.com/antoyo][Antoni Boucher]], lead developer of the ~rustc_codegen_gcc~ project, contributed code to ~gccrs~ this month, in order to improve target feature detection for both of our projects. This code concerns platform-specific information that the compilers needs to know about in order to produce correct assembly. By reusing the same code in both projects, we ensure that Rust code compiled using one of the GCC-based compilers will behave the same way on the users' machines. This change also makes it easier to adapt our target configuration values for Rust if the need arises. Thank you Antoni!
+In other technical news, [[https://github.com/antoyo][Antoni Boucher]], lead developer of the ~rustc_codegen_gcc~ project, contributed code to ~gccrs~ this month in order to improve target feature detection for both of our projects. This code concerns platform-specific information that the compilers needs to know about in order to produce correct assembly. By reusing the same code in both projects, we ensure that Rust code compiled using one of the GCC-based compilers will behave the same way on the users' machines. This change also makes it easier to adapt our target configuration values for Rust if the need arises. Thank you Antoni!
 
 Finally, a blogpost written in collaboration with the Rust project was also published on the official Rust blog: https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-compiler-for-rust.html. This blogpost outlines some of the decisions we've made for ~gccrs~ to make sure that the project does not threaten the Rust ecosystem and does not risk splitting it in two. The main discussion thread about it can be found [[https://www.reddit.com/r/rust/comments/1gm51ki/gccrs_an_alternative_compiler_for_rust_rust_blog/][here on Reddit]], where it was really well-received.
 
@@ -147,6 +147,7 @@ There are no calls for contribution this month, as we do not have a lot of good
 | alloc parser issues               |       100% |       100% |     - |  7th Jan 2025 |   31st Jun 2024 | 28th Jan 2025 |   GCC 15.1 |
 | let-else                          |         0% |         0% |     - | 28th Jan 2025 |               - | 28th Feb 2025 |   GCC 15.1 |
 | Explicit generics with impl Trait |         0% |         0% |     - | 28th Feb 2025 |               - | 28th Mar 2025 |   GCC 15.1 |
+| Downgrade to Rust 1.49            |         0% |         0% |     - |             - |               - |  1st Apr 2025 |   GCC 15.1 |
 | offset_of!() builtin macro        |         0% |         0% |     - | 15th Mar 2025 |               - | 15th May 2025 |   GCC 15.1 |
 | Generic Associated Types          |         0% |         0% |     - | 15th Mar 2025 |               - | 15th Jun 2025 |   GCC 16.1 |
 | RfL const generics                |         0% |         0% |     - |  1st May 2025 |               - | 15th Jun 2025 |   GCC 16.1 |