kivo's blog

Part 2: Tackling an `A-diagnostics` issue

2026-06-15T00:00:00+00:00

So it's been like a couple months since i wrote the last post about how i tackled an e-needs-test</code> issue</p>

This time, like i promised, i wanna go through something a bit more user-facing together with you - diagnostics</p>


Note</div>
A diagnostic is that nice, colored explanation the compiler shows you when something goes wrong. Instead of just shouting "error" and walking away, the compiler calmly points at what's off and usually nudges you toward a fix</p>

</div>
For example</p>
error[E0596]</span>: cannot borrow `*some_string` as mutable, as it is behind a `&` reference</span>
 --></span> src/main.rs:8:5
  |</span>
8 |</span>     some_string.push_str(", world");
  |</span>     ^^^^^^^^^^^ `some_string` is a `&` reference, so it cannot be borrowed as mutable</span>
  |</span>
help</span>: consider changing this to be a mutable reference
  |</span>
7 |</span> fn change(some_string: &mut</span> String) {
  |</span>                         +++</span>

For more information about this error, try `rustc --explain E0596`.
error</span>: could not compile `f` (bin "f") due to 1 previous error</span></pre>
Beautiful, isn't it? Well, the thing is they're not as perfect as they look at first glance. If we open the issues</a> we'll see a huge pile of issues on this topic, and even though the rust team puts a lot of effort into making them as user-friendly as possible (you know, those stories where you get 20kb of unreadable output from gcc), teachable and simple - i don't think it'll ever be possible to make them 100% perfect. But that doesn't mean we shouldn't improve them at all</p>
Picking an Issue</a></h2>
So let's grab an issue and try to solve one</p>

Fair warning</div>
I'll say right away, the difficulty in this area ranges from "change one word" to "rewrite half of the borrow checker". But on average it's pretty gentle and somewhere in between, so solving them is interesting and fun (mostly)</p>

</div>

Another fair warning</div>
Bear in mind that your experience may differ significantly from mine, because diagnostics permeate the entire compiler, from the lexer right through to MIR; there's so much going on that it's impossible to take everything into account: parser recovery, name resolution, type checking, trait resolution, borrow checking; and that's just a small part of it ><</p>

</div>
But you gotta pick the issue wisely, for the same reason as both warnings above</p>
This one</a> caught my eye</p>
Shortly, right now for this code</p>
fn take(_: impl Iterator<0>) {}
</code></pre>
The compiler gives this error</p>
error[E0107]</span>: trait takes 0 generic arguments but 1 generic argument was supplied</span>
  --></span> src/lib.rs:1:17
   |</span>
 1 |</span> fn take(_: impl Iterator<0>) {}
   |</span>                 ^^^^^^^^ expected 0 generic arguments</span>
   |</span>
note</span>: trait defined here, with 0 generic parameters
  --></span> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/iter/traits/iterator.rs:40:11
   |</span>
40 |</span> pub trait Iterator {
   |</span>           ^^^^^^^^</span>
help</span>: replace the generic bound with the associated type
   |</span>
 1 |</span> fn take(_: impl Iterator<Item =</span> 0>) {}
   |</span>                          ++++++</span></pre>
Which is wrong and doesn't make any sense</p>
And this code (it's a bit outdated)</p>

Important</div>
MGCA (min_generic_const_args</code>) is a nightly feature that lets you use const values directly as generic arguments - Trait<0></code> instead of Trait<K = 0></code>. That's what this whole second example lives in</p>

</div>
#![feature(min_generic_const_args)]
trait Trait { #[type_const] const K: i32; }
fn take(_: impl Trait<0>) {}
</code></pre>
Spits out this error</p>
error[E0107]</span>: trait takes 0 generic arguments but 1 generic argument was supplied</span>
 --></span> src/lib.rs:3:17
  |</span>
3 |</span> fn take(_: impl Trait<0>) {}
  |</span>                 ^^^^^--- help: remove the unnecessary generics</span>
  |</span>                 |</span>
  |</span>                 expected 0 generic arguments
  |</span>
note</span>: trait defined here, with 0 generic parameters
 --></span> src/lib.rs:2:7
  |</span>
2 |</span> trait Trait { #[type_const] const K: i32; }
  |</span>       ^^^^^</span></pre>
Even though it should suggest something like</p>
impl Trait<K = 0>
</code></pre>
Starting to Dig</a></h2>
First thing i make a clean branch</p>
$ git checkout -b fix-mgca-assoc-sugg
</code></pre>
And right away i kick off a compiler build</p>
$ ./x b
</code></pre>
So i don't have to do it later, plus I'll need to run the code above with the -Ztrack-diagnostics</code> flag to find at least the rough place where the diagnostic gets created</p>
While the compiler is building, one interesting detail about this issue - @fmease originally wanted to work on this problem but dropped his assignment</p>
Ideally it's worth messaging him to ask what went wrong and why he decided not to fix it further - as one of the people who knows this area well, he'd give the right hints and help out</p>

For newcomers</div>
Reaching out to whoever was originally on an issue (or anyone who knows the area) is one of the best moves you can make. In the overwhelming majority of cases people respond super positively - maybe not right away, but positively</p>

</div>
And so, 5 minutes later</p>
Build completed successfully in 0:04:57
</code></pre>
My compiler built (yeah I'm doing everything in real time, on one screen i have a text editor and on the other a code editor)</p>
Let's run it on the file right away and see what's going on</p>
gh-Kivooeo@dev-desktop-eu-1 ~/r/rust (fix-mgca-assoc-sugg) > ./build/aarch64-unknown-linux-gnu/stage1/bin/rustc -Ztrack-diagnostics /home/gh-Kivooeo/test_/src/main.rs --edition 2024
error[E0107]</span>: trait takes 0 generic arguments but 1 generic argument was supplied</span>
  --></span> /home/gh-Kivooeo/test_/src/main.rs:1:17
   |</span>
 1 |</span> fn take(_: impl Iterator<0>) {}
   |</span>                 ^^^^^^^^ expected 0 generic arguments</span>
   |</span>
   = note: -Ztrack-diagnostics: created at compiler/rustc_hir_analysis/src/hir_ty_lowering/generics.rs:575:18
note</span>: trait defined here, with 0 generic parameters
  --></span> library/core/src/iter/traits/iterator.rs:42:17
   |</span>
42 |</span> pub const trait Iterator {
   |</span>                 ^^^^^^^^</span>
help</span>: replace the generic bound with the associated type
   |</span>
 1 |</span> fn take(_: impl Iterator<Item =</span> 0>) {}
   |</span>                          ++++++</span>

error</span>: aborting due to 1 previous error</span></pre>
Let's look into compiler/rustc_hir_analysis/src/hir_ty_lowering/generics.rs:575:18</code>, hmm, at first glance this looks like exactly the function we need</p>
/// Checks that the correct number of generic arguments have been provided.
/// This is used both for datatypes and function calls.
#[instrument(skip(cx, gen_pos), level = "debug")]
pub(crate) fn check_generic_arg_count(
    cx: &dyn HirTyLowerer<'_>,
    def_id: DefId,
    seg: &hir::PathSegment<'_>,
    gen_params: &ty::Generics,
    gen_pos: GenericArgPosition,
    has_self: bool,
) -> GenericArgCountResult
</code></pre>
But looking at the logic, i don't see anything that could produce a suggestion like "add Item = 0</code>"</p>
Finding Where the Suggestion Is Born</a></h2>
So let's grep for the error text "replace the generic bound with the associated type". This grep found nothing except output in tests, so let's shorten it down to "replace the generic" and we immediately found what we need!</p>
fn suggest_removing_args_or_generics(&self, err: &mut Diag<'_, impl EmissionGuarantee>)
</code></pre>
And the specific check inside this function</p>
if !self.is_in_trait_impl() {
    let unused_generics = &self.gen_args.args[self.num_expected_type_or_const_args()..];
    let suggestions = iter::zip(unused_generics, &unbound_types)
        .map(|(potential, name)| {
            (potential.span().shrink_to_lo(), format!("{name} = "))
        })
        .collect::<Vec<_>>();

    if !suggestions.is_empty() {
        err.multipart_suggestion(
            format!(
                "replace the generic bound{s} with the associated type{s}",
                s = pluralize!(unbound_types.len())
            ),
            suggestions,
            Applicability::MaybeIncorrect,
        );
    }
}
</code></pre>
Here you can clearly see it by the suggestions</code> variable. Now we gotta think where to move next</p>
We have an interesting call chain through num_expected_type_or_const_args</code> which is used here, but it can't really help us much</p>
I didn't give you the full context above. Here's what the whole check looks like</p>
        // If there is a single unbound associated type and a single excess generic param
        // suggest replacing the generic param with the associated type bound
        if provided_args_matches_unbound_traits && !unbound_types.is_empty() {
            // Don't suggest if we're in a trait impl as
            // that would result in invalid syntax (fixes #116464)
            if !self.is_in_trait_impl() {
</code></pre>
Why did i do that? I didn't look at the outer checks right away myself, and the comments give pretty nice hints</p>
Let's look at how unbound_types</code> is defined</p>
let unbound_types = self.get_unbound_associated_types();
</code></pre>
Now let's look at this method</p>
    fn get_unbound_associated_types(&self) -> Vec<String> {
        if self.tcx.is_trait(self.def_id) { // ok that's true
            let items: &AssocItems = self.tcx.associated_items(self.def_id); // get assoc item, nice
            items
                .in_definition_order() // fetch it in def. order
                .filter(|item| {   // filter by:
                    item.is_type() // only assoc types
                        && !item.is_impl_trait_in_trait() // not trait
                        && !self
                            .gen_args
                            .constraints
                            .iter()
                            .any(|constraint| constraint.ident.name == item.name())
                            //^ exclude associated types that are already bound in the generic args
                })
                .map(|item| self.tcx.item_ident(item.def_id).to_string()) // map it to string
                .collect() // and collect
        } else {
            Vec::default() // otherwise just empty vec
        }
    }
</code></pre>
Anyway it's all clear. Surprisingly this code is pretty readable on its own, so let's make a simple change and see what happens?</p>
- item.is_type()
+ (item.is_type() || item.is_type_const())
</code></pre>
After that i run this interesting command</p>
$ ./x b --keep-stage 1 && ./build/aarch64-unknown-linux-gnu/stage1/bin/rustc -Ztrack-diagnostics /home/gh-Kivooeo/test_/src/main.rs --edition 2024
</code></pre>

Tip</div>
Use --keep-stage 1</code> if you don't wanna recompile std and core, despite the flags name it works exactly like that</p>

</div>
So... and for some reason it doesn't work</p>
error</span>: cannot find attribute `type_const` in this scope</span>
 --></span> /home/gh-Kivooeo/test_/src/main.rs:2:17
  |</span>
2 |</span> trait Trait { #[type_const] const K: i32; }
  |</span>                 ^^^^^^^^^^</span>
  |</span>
  = note: -Ztrack-diagnostics: created at compiler/rustc_resolve/src/macros.rs:1071:46</pre>
Ah right, i forgot to mention the code examples are a bit outdated. Now you have to write type const</code>, so the example becomes that</p>
And voila ✨</p>
error[E0107]</span>: trait takes 0 generic arguments but 1 generic argument was supplied</span>
 --></span> /home/gh-Kivooeo/test_/src/main.rs:3:17
  |</span>
3 |</span> fn take(_: impl Trait<0>) {}
  |</span>                 ^^^^^ expected 0 generic arguments</span>
  |</span>
  = note: -Ztrack-diagnostics: created at compiler/rustc_hir_analysis/src/hir_ty_lowering/generics.rs:575:18
note</span>: trait defined here, with 0 generic parameters
 --></span> /home/gh-Kivooeo/test_/src/main.rs:2:7
  |</span>
2 |</span> trait Trait { type const K: i32; }
  |</span>       ^^^^^</span>
help</span>: replace the generic bound with the associated type
  |</span>
3 |</span> fn take(_: impl Trait<K =</span> 0>) {}
  |</span>                       +++</span></pre>
The Actual Fix</a></h2>
Now the only thing left is to deal with the first case, where we get a really not-great diagnostic</p>
For that i think we can go back to the zip logic, because it's the thing that adds this suggestion. We need to filter it somehow</p>
Good news, this function is used only in this one specific place, so we can ruthlessly change its signature. I suggest this one</p>
fn get_unbound_associated_types(&self) -> Vec<&AssocItem>
</code></pre>
Not a string but the actual AssocItem</code>, so we don't have to do (String, bool)</code></p>
And we add a filter after the zip call, that checks the following - if we wanna suggest a const (like 0</code> for example) then we should check it's a type const</code>, and if we wanna suggest a type then we should check it's a type</p>
Literally just like this</p>
    .filter(|(potential, item)| match potential {
        hir::GenericArg::Const(_) => item.is_type_const(),
        hir::GenericArg::Type(_) => item.is_type(),
        _ => false,
    })
</code></pre>
Annd... yeah, it works!</p>
error[E0107]</span>: trait takes 0 generic arguments but 1 generic argument was supplied</span>
  --></span> /home/gh-Kivooeo/test_/src/main.rs:1:17
   |</span>
 1 |</span> fn take(_: impl Iterator<0>) {}
   |</span>                 ^^^^^^^^ expected 0 generic arguments</span>
   |</span>
   = note: -Ztrack-diagnostics: created at compiler/rustc_hir_analysis/src/hir_ty_lowering/generics.rs:575:18
note</span>: trait defined here, with 0 generic parameters
  --></span> library/core/src/iter/traits/iterator.rs:42:17
   |</span>
42 |</span> pub const trait Iterator {
   |</span>                 ^^^^^^^^</span></pre>
No more nonsense suggestion, just the error, exactly what we wanted</p>
Running the Test Suite</a></h2>
Great, now let's run ./x test ui</code> - I'm expecting a big number of regressions in our test suite</p>
To my surprise only two tests. Let's look at their contents</p>
First test: tests/ui/const-generics/issues/issue-87493.rs</code></p>
Looks like this</p>
pub trait MyTrait {
    type Assoc;
}

pub fn foo<S, T>(_s: S, _t: T)
where
    S: MyTrait,
    T: MyTrait<Assoc == S::Assoc>,
    //~^ ERROR: expected one of `,` or `>`, found `==`
    //~| ERROR: trait takes 0 generic arguments but 1 generic argument was supplied
{
}

fn main() {}
</code></pre>
The original error was this</p>
error[E0107]</span>: trait takes 0 generic arguments but 1 generic argument was supplied</span>
 --></span> src/main.rs:8:8
  |</span>
8 |</span>     T: MyTrait<Assoc == S::Assoc>,
  |</span>        ^^^^^^^ expected 0 generic arguments</span>
  |</span>
note</span>: trait defined here, with 0 generic parameters
 --></span> src/main.rs:1:11
  |</span>
1 |</span> pub trait MyTrait {
  |</span>           ^^^^^^^</span>
help</span>: replace the generic bound with the associated type
  |</span>
8 |</span>     T: MyTrait<Assoc =</span> Assoc == S::Assoc>,
  |</span>                +++++++</span></pre>
You know, just for fun i decided to try writing what the compiler suggests here, and you know what i got? You'll never guess...</p>
help</span>: replace the generic bound with the associated type
  |</span>
8 |</span>     T: MyTrait<Assoc =</span> Assoc = Assoc == S::Assoc>,
  |</span>                +++++++</span></pre>
I tried it. The compiler responded with an even more broken version of the same suggestion - Assoc = Assoc = Assoc == S::Assoc</code>. A beginner could sit there applying this forever... After our fix this problem got fixed and now it (kinda) correctly suggests the fix</p>
error</span>: expected one of `,` or `>`, found `==`</span>
 --></span> /home/gh-Kivooeo/test_/src/main.rs:8:22
  |</span>
8 |</span>     T: MyTrait<Assoc == S::Assoc>,
  |</span>                      ^^ expected one of `,` or `>`</span>
  |</span>
  = note: -Ztrack-diagnostics: created at compiler/rustc_parse/src/parser/diagnostics.rs:2528:34
help</span>: if you meant to use an associated type binding, replace `==` with `=`
  |</span>
8 </span>-     T: MyTrait<Assoc == S::Assoc>,</span>
8 </span>+     T: MyTrait<Assoc = S::Assoc>,</span>
  |</span></pre>
At least it compiles if you do what the compiler asks :)</p>
Now let's look at the second test</p>
//! This test used to ICE: #121134
//! The issue is that we're trying to prove a projection, but there's
//! no bound for the projection's trait, and the projection has the wrong
//! kind of generic parameter (lifetime vs type).
//! When actually calling the function with those broken bounds, trying to
//! instantiate the bounds with inference vars would ICE.
#![feature(unboxed_closures)]

trait Output<'a> {
    type Type;
}

struct Wrapper;

impl Wrapper {
    fn do_something_wrapper<O, F>(&mut self, _: F)
    where
        F: for<'a> FnOnce(<F as Output<i32>>::Type),
        //~^ ERROR: trait takes 0 generic arguments but 1 generic argument was supplied
    {
    }
}

fn main() {
    let mut wrapper = Wrapper;
    wrapper.do_something_wrapper(|value| ());
}
</code></pre>
Anyway, some complicated code, but what's interesting, right now the compiler suggests the following - add Type = </code></p>
help</span>: replace the generic bound with the associated type
   |</span>
18 |</span>         F: for<'a> FnOnce(<F as Output<Type =</span> i32>>::Type),
   |</span>                                        ++++++</span></pre>
And after we add Type = i32</code>, it suggests this</p>
error[E0229]</span>: associated item constraints are not allowed here</span>
  --></span> src/main.rs:18:40
   |</span>
18 |</span>         F: for<'a> FnOnce(<F as Output<Type = i32>>::Type),
   |</span>                                        ^^^^^^^^^^ associated item constraint not allowed here</span>
   |</span>
help</span>: consider removing this associated item binding
   |</span>
18 </span>-         F: for<'a> FnOnce(<F as Output<Type = i32>>::Type),</span>
18 </span>+         F: for<'a> FnOnce(<F as Output<>>::Type),</span></pre>
What...? Yeah, this was kinda to the point about diagnostics not being perfect in the compiler. Anyway i ran around in circles for a pretty long time trying to do what the compiler suggests, and in the end it just didn't compile</p>
Anyway, i think this isn't our problem anymore :)</p>
The very fact that the compiler no longer suggests adding Type =</code> here is already a win, and the other diagnostics fall out of scope of this fix</p>
So with a calm soul we update the tests so they run with the new expected output. For the first one we just run with --bless</code></p>
$ ./x test tests/ui/const-generics/issues/issue-87493.rs tests/ui/traits/generic_param_mismatch_in_unsatisfied_projection.rs --bless
</code></pre>
And now we look</p>
running 2 tests
..

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 21417 filtered out; finished in 51.58ms
</code></pre>
Perfect!</p>
Wrapping Up</a></h2>
Now, the last thing left to do is write a new test and add @fmease's suggestion to change the wording of this error</p>
format!(
-    "replace the generic bound{s} with the associated type{s}",
+    "turn the generic argument{s} into an associated item binding{s}",
    s = pluralize!(unbound_types.len())
)
</code></pre>
Now let's add a new test, if you don't know how to do that i suggest you read the previous post</a> about adding tests!</p>
Here's what our test will look like</p>
//! Regression test for <https://github.com/rust-lang/rust/issues/151602>.

#![feature(min_generic_const_args)]

trait Trait {
    type const K: i32;
}
fn take(_: impl Trait<0>) {}
//~^ ERROR: trait takes 0 generic arguments but 1 generic argument was supplied [E0107]

fn main() {}
</code></pre>
Since we changed the error wording, we'll need to run all the tests again and update the .stderr</code> files for all of them</p>
$ ./x test ui --bless
</code></pre>
I think after that the only thing left is to open the pull request and assign @fmease to it (using r?</code>)</p>
What Happens Next?</a></h2>
While the tests are running, let's talk about this for a sec. I actually admit there might be some edge cases in this fix or the test, I'm not super familiar with the MGCA feature, even though i wrote the Ctor support and a couple other things for it. That was more thanks to the great mentorship and review from @BoxyUwU</p>
Also a lot of useful info on this matter was said here</a></p>
Well, it seems tests are compiled fine, except one test which requiers me to update the error:</p>
fn trait_bound_generic<I: T<u8, u16>>(_i: I) {
    //~^ ERROR trait takes 0 generic arguments
-    //~| HELP replace the generic bounds with the associated types
+    //~| HELP turn the generic arguments into an associated item bindings
}
</code></pre>
So it felt to me that fix is very ready for being published, let's run ./x test tidy</code> to make very sure before opening a PR. Good, tidy</code> seems fine about it</p>
Build completed successfully in 0:00:41
</code></pre>
Next step is to open a PR (done here</a>), assign @fmease with r?</code> and... well, that's basically it - now we wait :)</p>
The Review Comes Back</a></h2>
So the wait wasn't that long actually, and @fmease left a few comments. And honestly this is the part i enjoy the most - when someone who knows the area way better than you looks at your code and points at the spots you were too eager to skim past</p>
The first and the most important one was about my filter. Remember this part?</p>
.filter(|(potential, item)| match potential {
    hir::GenericArg::Const(_) => item.is_type_const(),
    hir::GenericArg::Type(_) => item.is_type(),
    _ => false,
})
</code></pre>
Looks fine right? Well, the thing is i was zipping unused_generics</code> with unbound_types</code> by position</strong>, and only then filtering by kind. But the assoc items come in definition order, and the generic args come in the order the user wrote them - there's no reason these two line up. @fmease gave a really clean example</p>
trait Trait { type A; type const B: usize; }
fn f<T: Trait<(), 0>>(); // my PR emits a suggestion
</code></pre>
trait Trait { type const A: usize; type B; }
fn f<T: Trait<(), 0>>(); // my PR does *not* emit one
</code></pre>
In the second case the zip produces pairs like [(TyAssocConst, Ty), (AssocTy, Const)]</code> and neither pair survives the filter, so we just silently drop a perfectly good suggestion. Oops</p>
The fix is to stop pairing by position entirely. Instead i split the unbound items into two lazy iterators by kind, and let each generic arg pull the next item of its own</strong> kind</p>
let mut unbound_assoc_consts = unbound_assoc_items.iter().filter(|item| item.is_type_const());
let mut unbound_assoc_types = unbound_assoc_items.iter().filter(|item| item.is_type());
let suggestions = unused_generics
    .iter()
    .filter_map(|potential| {
        let item = match potential {
            hir::GenericArg::Const(_) => unbound_assoc_consts.next(),
            hir::GenericArg::Type(_) => unbound_assoc_types.next(),
            _ => None,
        }?;
        Some((
            potential.span().shrink_to_lo(),
            // FIXME: This doesn't account for generic associated items
            format!("{} = ", self.tcx.item_ident(item.def_id)),
        ))
    })
    .collect::<Vec<_>>();
</code></pre>
Each .next()</code> advances its own cursor, so a type arg always grabs the next assoc type and a const the next assoc const, no matter how they're interleaved - and ?</code> just bails (emitting nothing) if a queue runs dry instead of mispairing</p>
The second comment was a tiny but nice one. The wording</p>
"turn the generic argument{s} into an associated item binding{s}"
</code></pre>
reads totally fine in singular, but the moment you have more than one it becomes "turn the generic arguments into an</strong> associated item bindings" which is, well, not english. So the an</code> should only show up when there's exactly one. Quick fix</p>
let s = pluralize!(suggestions.len());
let article = if suggestions.len() == 1 { "an " } else { "" };
err.multipart_suggestion(
    format!("turn the generic argument{s} into {article}associated item binding{s}"),
    suggestions,
    Applicability::MaybeIncorrect,
);
</code></pre>
Also notice i switched the pluralization from unbound_types.len()</code> to suggestions.len()</code> - now that not every excess arg necessarily produces a binding, the count should reflect what we actually suggest</p>
Then there was the comment above the whole block, which was honestly just a bit outdated. It still said</p>
// If there is a single unbound associated type and a single excess generic param
// suggest replacing the generic param with the associated type bound
</code></pre>
but the code handles multiple of them now, and assoc consts too, not only types. @fmease suggested generalizing it</p>
// If there is an identical amount of unbound associated items and excess generic args
// suggest turning the generic args into associated item bindings.
</code></pre>
with a funny little caveat that even "identical amount" isn't strictly true anymore after my kind-matching change (equal counts no longer guarantee a full set of bindings, since a type only pairs with a type and a const with a const). But it's still way better than the old wording, so in it goes</p>
And the last one - @fmease asked me to drop a // FIXME: This doesn't account for generic associated items</code> right above the format!("{} = ", …)</code>, since that's the bit that can't express a generic assoc item like type Assoc<T>;</code> (we'd produce Assoc =</code> with nowhere to put its generics). A separate (preexisting) bug, but a FIXME</code> is the honest thing to leave behind</p>

Tip</div>
Don't be shy to leave FIXME</code>s. A FIXME</code> that names a real limitation is much more useful than pretending the code is perfect - it's basically a little note to the next person (or future you)</p>

</div>
Round Two of Nits</a></h2>
I pinged @rustbot ready</code> and, like clockwork, a second smaller round came back. This one was the comfy kind - all naming and wording, nothing scary</p>
The running theme was "make names tell the truth": a variable still called unbound_types</code> was actually holding assoc consts too by now, so it got an honest rename, a one-off helper with a misleading name got inlined away, and a comment that said generic param</em> where it meant generic arg</em> got fixed (this corner of the compiler mixes those two up constantly)</p>

Important</div>
A big chunk of review comments are exactly this - a name, a word, a stale comment. It's not "you did it wrong", it's just how code stays readable for whoever touches it next, and it's the easiest kind of feedback to address</p>

</div>
He also asked for one more test: that we don't</em> suggest nonsense for a plain Iterator<0></code>. So i extended some test under tests/ui/suggestions/</code></p>
pub trait T<X, Y> {
    type A;
    type B;
    type C;
}
pub struct Foo {
    i: Box<dyn T<usize, usize, usize, usize, B = usize>>,
    //~^ ERROR trait takes 2 generic arguments but 4 generic arguments were supplied
}

fn take(_: impl Iterator<0>) {} // <- here is what i've actually added !!!
//~^ ERROR trait takes 0 generic arguments but 1 generic argument was supplied

fn main() {}

</code></pre>
The whole point is the .stderr</code> has no</em> "turn the generic argument" help - Iterator</code> has an assoc type but no assoc const, so the const queue is empty and we suggest nothing, exactly as intended</p>
After all that the suggestion finally does the right thing even in the weird ordering cases, the grammar is correct in both singular and plural, the names say what they mean, and the comment doesn't lie anymore</p>
And now this is ready for merge 🎉 🎉 🎉</p>
What I Hope You Take From This</a></h2>
If there's one thing i want you to leave with, it's that you really don't need to understand the whole compiler to make a diagnostic better. We took something that suggested complete nonsense, followed -Ztrack-diagnostics</code> to the rough spot, found the exact code with a lazy grep, and made the suggestion only show up when it actually makes sense</p>
A-diagnostics issues are great for this - a lot of them sit comfortably in the easy-to-medium range, they're user-facing so your work is immediately visible, and the people you'll meet along the way are genuinely kind</p>
So if any of this looked fun - go pick one, grep around, ask questions, and don't be afraid to be wrong. That's literally how all of us started</p>
And honestly, if you wanna try one but feel a little lost - you can just assign me as your reviewer with r? @Kivooeo</code> (or ping me anywhere), i'm always happy to mentor newcomers on any kind of issues</p>

On a side note, if you want to support future blog posts, my work on the compiler and mentoring newcomers, i'd be really grateful if you took a look at my sponsor page</a> <3</p>



Part 1: Tackling an `E-needs-test` issue
2026-02-14T00:00:00+00:00
In this part, I want to cover how I would tackle an issue labeled E-needs-test</code>.</p>
I'll also be mentoring a Google Summer of Code project this year, and it's test-suite related - so if you're interested, you can read more about it here</a></p>
Given that this isn't a very time-consuming task, I expect this post won't be very long. I'll document everything as I go - you'll see my actual thought process and decisions in real-time</p>
Selecting and Studying an Issue</a></h2>
Let's head over to GitHub</a> to search for issues. Looking at the list, I'll pick the first available issue. I don't think it will make a big difference, and to be honest, picking one at random for content isn't a bad idea either</p>
So I've selected an issue</a>, now let's see what's going on. According to the issue description, this code used to cause the compiler to panic when trying to compile it. However, according to the last comment, the problem was fixed in one of the pull requests, even though the issue itself is still open. Therefore, we want to add a test using this code example that used to panic, to lock in the new correct behavior and ensure that it now works as expected</p>
Tackling the Problem</a></h2>
So, now that we've looked into the issue's context, let's start taking action. Let's open a code editor, and navigate to forked repository, and create a new branch for pull request. I'm just going to do what I normally do (to be honest, I still don't feel very confident using Git, so I might do something a bit odd or not the usual way):</p>

Tip</div>
If you're also not confident with Git, that's totally fine - the commands I show here work reliably, and the worst case is that reviewers will help you fix any Git issues</p>

</div>
$ git checkout -b add-regression-test-1
</code></pre>
And also, to ensure I've a clean and up-to-date branch, I run:</p>
$ git fetch upstream
$ git reset --hard upstream/main
</code></pre>

Fair warning</div>
reset --hard</code> will discard all your uncommitted local changes. Make sure you don't have any unsaved work before running this command. I always verify this first, which is why I use it safely</p>

</div>

Note</div>
This fetches the latest changes from the main Rust repository and resets branch to match it exactly</p>

</div>
Now let's figure out where to add a new test. Since it'll be a UI test, I should find the appropriate subdirectory to place it. Since the issue was titled "resolve: no entry found for key</code>", it's clear this is a name resolution problem, which means the test should go in the resolve directory</p>
Also a very small tip on how can you determine the directory, because in your case it might not be specified in the issue's title, in that case feel free to look at labels on that issue, it's very likely do have labels like A-resolve</code> or A-macros</code> like in my case, and you can search for this words in tests/ui/README.md</code>, also, try to use your own intuition to understand what is tested in that test (sometimes it's not very obvious, I completely relate that part)</p>
Let's open tests/ui/README.md</code> and search for "resolve", to see what's available:</p>
$ code tests/ui/README.md
</code></pre>
I use Ctrl+F to search for 'resolve'. Aha, there it is: there's a directory with the exact name I need:</p>

tests/ui/resolve/</code>: Name resolution</a></h2>
See Name resolution | rustc-dev-guide</a>.</p>
</blockquote>
That's exactly what I need! Now let's think of a name for the test. It should be short and reflect what's being tested. To help with this, let's look at the code for the future test, which is taken from the example:</p>
#![feature(decl_macro)]

macro_rules! exported {
    () => {
        #[macro_export]
        macro_rules! exported {
            () => {};
        }
    };
}
use inner1::*;
exported!();
mod inner1 {
    pub macro exported() {}
}
</code></pre>
This is some really convoluted nested macro code! Honestly, I have no clue what could have gone wrong here. I tried reading yaahc's comments on the issue, but they didn't give me much insight, and I must admit I'm hearing about the decl_macro</code> feature almost for the first time</p>
I honestly don't fully understand what this code does, but for adding a regression test, I don't need to - the bug was already fixed, I just need to make sure this code compiles now</p>
I'll make a relatively generic test name and adding the issue number at the end. Something like exported-macro-in-mod-147958</code> - honestly, I just wrote down what I see in the test itself</p>
$ touch tests/ui/resolve/exported-macro-in-mod-147958.rs
$ code tests/ui/resolve/exported-macro-in-mod-147958.rs
</code></pre>
So I just paste the code above into this file. The only difference is that I'll add a directive at the very top of the test:</p>
//@ check-pass
</code></pre>
In UI tests, if you don't specify a directive like //@ check-pass</code>, the harness assumes the test should produce errors and compares against a .stderr file</p>
I won't go into detail about test directives here, because there's already good material on this topic. My focus is a bit different, but I highly recommend checking out the Rustc dev guide on directives</a></p>
Okay, now that the test is ready, let's try running it:</p>
$ ./x test tests/ui/resolve/exported-macro-in-mod-147958.rs
</code></pre>
This will start building the compiler and any necessary tools. By the way, since I expect no errors to occur, a .stderr</code> file shouldn't be generated, so I didn't use the --bless</code> flag (the one that generates the error output file)</p>
The test didn't pass...</p>
running 1 tests

[ui] tests/ui/resolve/exported-macro-in-mod-147958.rs ... F


failures:

---- [ui] tests/ui/resolve/exported-macro-in-mod-147958.rs stdout ----
Saved the actual stderr to `/home/gh-Kivooeo/r/rust/build/aarch64-unknown-linux-gnu/test/ui/resolve/exported-macro-in-mod-147958/exported-macro-in-mod-147958.stderr`
normalized stderr:
error[E0601]</span>: `main` function not found in crate `exported_macro_in_mod_147958`</span>
  --></span> $DIR/exported-macro-in-mod-147958.rs:15:2
   |</span>
LL |</span> }
   |</span>  ^ consider adding a `main` function to `$DIR/exported-macro-in-mod-147958.rs`</span>

error</span>: aborting due to 1 previous error</span>

For more information about this error, try `rustc --explain E0601`.</pre>
Ah, I forgot to add a main</code> function. Of course, I could have added a directive like //@ compile-flags: --crate-type lib</code> to indicate this is a library, but I'm more used to just adding an empty main</code> function</p>
Alright, that's it. I can also run ./x test tidy</code> just to make sure there's no trailing whitespace and that I didn't forget a newline at the end of the file</p>

Note</div>
tidy checks formatting, whitespace, file placement, and other repository conventions</p>

</div>
Now I can prepare the pull request. To do that I ran the following commands:</p>
user@machine ~/r/rust (add-regression-test-1)> git add .
user@machine ~/r/rust (add-regression-test-1)> git commit -m "add regression test"
user@machine ~/r/rust (add-regression-test-1)> git push --force-with-lease origin add-regression-test-1 
</code></pre>

Note</div>
--force-with-lease</code> isn't needed for a new branch, but I use it out of habit</p>

</div>
I think everything is ready, so let's go to GitHub. I'll open my fork, switch to the branch I created for this pull request, and click the big "Contribute -> Open pull request" button</p>
I'll keep the description minimal, since there is not much to tell about this PR. I titled it "add regression test for 147958" and I just left the description as "fixes #147958", so that the issue will be closed after merging the pull request</p>
Since I don't know who should do the review, I left it like that. Usually, you can write something like r? team</code> (e.g. r? compiler</code>) or a specific member like r? Kivooeo</code>. If you don't specify anyone, rustbot will pick the most appropriate free reviewer in rotation</p>

And that's it. Pull request was created here</a>. Rustbot assigned TaKO8Ki as the reviewer, so now I wait for review. I'm not 100% sure about this test since I'm not familiar with this feature, but I fully expect it to be approved. You can also check the reviewer's GitHub profile to see their recent activity - I often do this myself, although I don't really have any specific expectations. Reviews can take up to two weeks before you can re-request a review if needed</p>
Given the size and simplicity of this PR, I'm expecting a pretty quick approval. The most likely outcome is that another contributor will approve it or suggest corrections</p>
An Oversight</a></h2>
About 30 minutes after I created the pull request, I remembered that I forgot to add a most important comment</p>
//! Regression test for <https://github.com/rust-lang/rust/issues/147958>
</code></pre>
On top of the test, so in future it would be easier to navigate for original issue, let's quickly fix it!</p>
So all I do is just add this comment, final test looks this</p>
//! Regression test for <https://github.com/rust-lang/rust/issues/147958>

//@ check-pass

#![feature(decl_macro)]

macro_rules! exported {
    () => {
        #[macro_export]
        macro_rules! exported {
            () => {};
        }
    };
}
use inner1::*;
exported!();
mod inner1 {
    pub macro exported() {}
}

fn main() {}
</code></pre>
Here I have an empty main</code> function, and a comment with link to the issue, btw, worth noting that while many regression tests don't include this comment (and that's totally okay), I personally find it really helpful to have the direct link. I also pretty often see comment like:</p>
//! Test for #31233
</code></pre>
Which makes it pretty hard to follow an actual issue, ctrl + click by link is way faster and easier</p>
Next what I do is some git</code> magic, at least this is how I see this</p>
$ git add .
$ git commit --amend --no-edit
$ git push --force-with-lease origin add-regression-test-1
</code></pre>
Now that's 100% ready :)</p>
What to expect during review</a></h2>
Now let's talk a bit about what you can expect from the review process itself. I won't be able to show this part directly in the blog post, but readers can check out the pull request I created above to see if there's any review activity. I fully expect there might be some requested changes to my pull request, but let me describe the most common scenarios that might happen after you create your PR:</p>


CI fails due to tidy issues:</p>

There might be trailing whitespaces</li>
You forgot to add a newline at the end of the file</li>
You created a test in the root of tests/ui</code> - which has been recently prohibited, tests must now be in subdirectories</li>
You used an unclear test name - we now discourage names like issue-123.rs</code></li>
</ul>
</li>

You'll be asked to rename the test, and the reviewer will likely suggest a more appropriate name</p>
</li>

You'll be asked to move the test to a more suitable directory</p>
</li>

You'll be asked to modify the test in some way:</p>

Add a comment</li>
Change or add directives</li>
Adjust the test code itself</li>
</ul>
</li>
</ol>

These are all completely normal situations that just need small fixes. Think of review feedback as collaborative teamwork and suggestions for improvement, not as criticism of your work. Every contributor goes through this!</p>
Conclusion</a></h2>
That's it! We went from finding an issue to submitting a PR in about 15-20 minutes. E-needs-test</code> issues are perfect first contributions because:</p>

They're low-risk (just adding a test, not changing compiler logic)</li>
The solution is usually straightforward (the bug is already fixed)</li>
You get familiar with the test suite structure</li>
You learn the PR workflow without much pressure</li>
</ul>

It is important to add at the end that, depending on the issue itself, the process may differ slightly, for example, a different directory for the test or the test will expect an error output (i.e., the creation of a .stderr</code> file), so you may have questions. If you want to try adding a test or solving an issue labeled E-needs-test</code>, but are stuck or feel like you don't know something, you can write to me in private messages</a> on Zulip and/or assign me as a reviewer using r? Kivooeo</code> in the description. Thank you to everyone who works on Rust and everyone who will work on it in the future!</p>
In the next part I'm planning to take some A-diagnostics issue, to actually fix some error messages, yay!</p>

On a side note, if you want to support the release of future blog posts, my work on the compiler, mentoring newcomers and GSoC students, I'd be very grateful if you could take a look at my sponsor page</a> <3</p>


So You Want to Contribute to Rust
2026-01-28T00:00:00+00:00
Before we start:</em></p>
This post is long and detailed on purpose. It's not meant to be read linearly or "from start to finish". If you're just getting started, it's perfectly fine to read only the parts that feel useful right now and ignore the rest until later</p>

I</p>
I</p>
I</p>
Have you ever opened the rust-lang/rust</a> repo and felt overwhelmed by the sheer number of files, tests, and issues? Like you're stuck in "analysis paralysis</a>" - so many options and so much complexity that you freeze and don't know where to start. If you feel ambitious and/or have time and energy to help people around the world and support your favorite programming language? Please, pull up a chair - this story is for you!</p>
To be honest, I personally didn't have that stuck feeling at start, but most people who ask me how to get started do</p>
Finding Something to Work On</a></h2>
First, let's go to the rust-lang/rust</a> repo. (Important note: this applies to other Rust repos like clippy</a> or rustfmt</a> too - they also need contributors) Now stop for a moment and ask yourself: do you know what you want to work on?</p>
If your answer is "no", that's totally fine! A good first step is to start looking for an interesting task in this huge space of issues. There are tons of things to do - some exciting and some more routine. Here are a few beginner-friendly areas you might start with:</p>


Diagnostics</a>: This is the part of the compiler that handles our error messages. You can help make these messages clearer or fix cases where the current message is confusing or misleading</p>
</li>

E-needs-test label</a>: Rust's test suite is enormous but still incomplete. An issue with this label has a bug fixed in the code but no test was added. You can add a test case to capture that fix so it doesn't accidentally break in the future. These tasks usually involve small changes and are very valuable</p>
</li>

E-mentor label</a>: This label means a mentor has offered to help with the issue. It's perfect for newcomers because you'll have someone experienced ready to answer your questions as you work on it</p>
</li>

E-easy: I don't really want to recommend it because this particular label often attracts a lot of attention and a kind of battle for the issue begins</p>
</li>

C-enhancement</a>: could be useful, it's not always about the code and might be less stressfull</p>
</li>
</ol>
My First Contribution Story</a></h2>
Let me digress a bit and share how I made my first contribution to the Rust compiler. One evening I was relaxing with no plans and watching a video</a> by Tsoding about Rust. In it, he tried to access a struct field through a raw pointer using the -></code> operator. In Rust, you can't do that, that's a C/++ thing, but the compiler still knows what you meant to do. In this example, the error message was actually pretty misleading</p>
So here is what roughly Tsoding was trying to do</p>
struct Point {
    x: i32,
    y: i32,
}

fn main() {
    let s = Point { x: 0, y: 2 };

    let p = &s as *const Point;

    p->x;
}
</code></pre>
Before my fix, the diagnostic was looks like this</p>
help: `xs` is a raw pointer; try dereferencing it
   |
LL |         (*p)->x;
   |         ++  +
</code></pre>
As you can see here, it correctly asks you to dereference it, but keep a -></code> which still isn't a valid Rust code</p>

Suddenly something clicked in my head: "What's stopping me from start right now and fix that error message?", and I got excited by this idea. At that moment I had literally no open-source experience and didn't even know git well, so I went online to learn what a pull request is and how to make one :)</p>
After some effort, I managed to fork the repository and dive into the code. Then I instantly hit the next roadblock: "There are millions of lines here - how do I find where this error message is generated?" Luckily, luck was on my side. I searched the repository for a unique part of the error text and found a .ftl</code> file - that's a Fluent template for error messages. From there I tracked down the diagnostic struct in the code and finally found where it was being created</p>

I scribbled together a more-or-less working fix and submitted a PR</a>. I still didn't understand a lot of the basics - for example, I didn't know how to re-run the tests with the --bless</code> flag to update expected output. Despite my inexperience, the reviewers (who are amazing people) did most of the heavy lifting, but I loved the experience. It was completely new to me. While that first PR was under review, I already started on a second one: I found another small issue and fixed it. The second PR</a> turned out to be much simpler and got merged even faster than the first</p>
And that's how I stayed involved in the project. I kept finding and fixing interesting problems, all while chatting and collaborating with many really cool people</p>
Here is how that error message looks now after my and reviewers efforts:</p>
help: `p` is a raw pointer; try dereferencing it
   |
11 -     p->x;
11 +     (*p).x;
</code></pre>
I</p>
I</p>
I</p>
Thanks for sticking with me through that story! Now, back to the main topic: I want to emphasize something important. Many new contributors (and this is often a mistake) focus on counting merges or commits - chasing those numbers. I believe that's fundamentally the wrong approach and often leads to burnout. I know it sounds weird coming from someone who did 100 merges in the first 6 months just for fun ^^, but honestly, I was just enjoying learning and helping. It was only later that I realized how many that was! Trust me, don't worry about the count - concentrate on the learning and the enjoyment</p>
btw, there's plenty of work you can do without writing a line of code. For example, we already talked about adding tests for E-needs-test</code> issues. Other contributions include triaging issues, improving documentation, or helping to reproduce bugs (E-needs-mvce</code>). These non-code contributions are also very valuable</p>
Small practical step about assigning to issues</a></h2>
Let's say you've found an issue you like and want to work on it. That's great! To show others that you're already working on it, you can use our bot (actually, there's a real person sitting there assigning labels, who knows). - rustbot</code>, or more specifically @rustbot claim</code> to assign yourself and @rustbot release</code> to remove the assignment from yourself (which is totally fine!).</p>
Big practical steps</a></h2>
Once you've claimed an issue, it's time to set up your environment. The first major step is to build the compiler (good page</a> about it). This in average takes 10-15 minutes, usually 5-8 minutes and rarely it's more than 30 minutes, recompiles after small changes is usually faster, so don't worry (also using tip 2 from the end could help you with recompiling time)</p>

If you already have an idea of what you want to work on (maybe you found a bug that interests you or a feature you want to add), it's hard to give one-size-fits-all advice - it really depends on your chosen task</p>
One thing I will strongly encourage is: don't be afraid to ask questions. When maintainers see someone who is genuinely interested and trying to understand, we jump in to help and explain as much as we can</p>
Of course, asking questions out loud can be scary, and it's totally normal to feel shy. Even if you're hesitant, I still recommend live communication: for example, the Rust Zulip chat</a> is great for quick back-and-forth, or you can comment directly on the GitHub issue. If the person who filed the issue is a core team member, they often respond to questions there. Otherwise, someone on the team or the community will likely see your question and help out</p>

Here's a somewhat surprising tip for those who are really stuck: try asking LLM for help. I know, I know - the community is skeptical about language models and no one likes spammy answers/contributions/PRs. I'm a reviewer too, and I know it very well. The key is how</em> you use it</p>
Please don't ask the language model to write a code for you if you don't understand it. Instead, ask specific and concrete questions about your task</p>
For example, "How do I find where this function is defined in the compiler?" or "What does this part of the code do?", language models are pretty good at that. Their suggestions aren't perfect (they usually won't know the quirks of codebase), but they can give you a starting point or point you at the right file. For some people, that little hint is enough to move forward :3</p>

I recently reviewed a pull request that fixed an error message with the assert!</code> and the returned value. In that case, we needed to detect whether the if</code> came from the assert!</code> or not. The author's method wasn't perfect</p>
I decided to conduct my own investigation to suggest a better approach, and I realised that I knew what I was looking for, but I couldn't search for it due to my limited knowledge of regex and grep. So, I described what I was looking for to the LLM, which provided me with some rg</code> commands. I simply copied and pasted them into the terminal and started searching with them</p>
I found what I was looking for! I could also suggest a better, more idiomatic way for the author to rewrite it</p>
When You Get Stuck</a></h2>
Let's say you've opened the code and started digging in, but after a week you still feel stuck and don't know how to proceed. That's a very common feeling - nothing to panic about</p>
If you've hit a wall, I suggest asking for help as we've discussed it above: post a question on Zulip or on the GitHub issue itself (remember, you can mention people, or just write a polite question). Often the issue author or someone else will spot it and give pointers</p>

Another perfectly fine approach is to put the issue aside for now. Maybe you tried to make progress and realized you're blocked or don't have time at the moment</p>
That happens to everyone. If you do put it on hold, leave a note in the issue about what you tried and what the obstacles were</p>
For example: "I explored the code around X</code> and tried using Y</code>, but I'm not sure if that's the right approach. I'm stuck on how to proceed", yes, you didn't fix the issue, but you've saved the next person who picks it up a lot of time - they'll know where you left off and what you've already tried</p>
Your First PR</a></h2>
Now imagine you finally decide to tackle an issue and make your first pull request. You might wonder, "What makes a good PR?", here's the thing: any contribution is welcome. Really! Even if you're just fixing a typo in documentation, adding a test, or cleaning up a bit of code for readability, it's all valuable</p>
I don't like to divide contributions into "good" or "bad." The more important part, imo, is that you did it yourself: you wrote the code and you wrote the PR description. It might be challenging at first, but we want to see your thought process and how you understand the problem. Write a clear summary of what you did in the PR so reviewers can follow along with your reasoning</p>

Personal example: in my first PRs, I often made suboptimal code choices (and honestly, I still do sometimes). At first I didn't know most of the codebase. The reviewers were super helpful and always suggested a more idiomatic or correct approach.</p>
For instance, they might say, "You don't need to implement this yourself - there's already a method doing this", there has never been (and I hope never will be) an occasion where someone yelled at me for writing imperfect code or doing mistakes. We all make mistakes - it's part of learning. Even the core team members make mistakes. The reviewers' job is to help improve the code, not to shame you</p>
Sometimes Even a Well-Crafted PR Gets Closed</a></h2>
Not every contribution ends up merged - and that's okay. Sometimes the code is fine, but the idea behind it isn't what the community wants. Here's a personal example:</p>
I once submitted a PR</a> that aimed to suggest using method syntax x.max(y)</code> when someone wrote max(x, y)</code> but hadn't imported the function. The fix itself was clean and worked correctly:</p>
   else if ["max", "min"].contains(&item_str.as_str())
        && let PathSource::Expr(Some(Expr {
            kind: ExprKind::Call(_, args),
            span: call_span,
            ..
        })) = source
        && args.len() == 2
        && let Some(arg0) = self.r.tcx.sess.source_map().span_to_snippet(args[0].span)
        && let Some(arg1) = self.r.tcx.sess.source_map().span_to_snippet(args[1].span)
    {
        Some((
            *call_span,
            "you may have meant to use the method syntax",
            format!("{arg0}.{item_str}({arg1})"),
        ))
    }
</code></pre>
Some team members preferred the free function (std::cmp::max(x, y)</code>) because it's symmetric and feels more natural for a binary operation. The PR wasn't rejected because of bad code - it was a stylistic disagreement</p>
Just keep in mind, that even a "failed" PR is a win if you learn from it. Not every issue needs fixing the way you first think. Sometimes the best contribution is realizing when to step back</p>
Another example of anti-success of mine</a></h2>
I want to share one more personal example that might be useful, especially if you're worried about "breaking something"</p>
Recently, I worked on a fairly large PR</a> that introduced new logic for the MGCA feature. It wasn't a small change: it added quite a bit of new code, went through a long review process, and required several iterations to address feedback. After many discussions and refinements, it finally got merged</p>
The PR was well reviewed, had good test coverage, and didn't cause any regressions in the existing test suite. At that point, everything looked solid</p>
A few days ago, I randomly stumbled upon a new issue</a>. I wasn't pinged, mentioned, or otherwise notified - I just happened to see it while browsing. The issue described a problem that appeared after my PR landed</p>
And this is the important part: this kind of thing is completely normal</p>
Even carefully reviewed changes with good tests can expose new edge cases or interactions that weren't obvious at the time. The compiler is a huge, complex system, and no one can predict all consequences upfront</p>
What matters is not that a bug appeared, but how you react to it</p>
I assigned the issue to myself and left a short note saying that I'd take a look when I had time. Not because I felt guilty, but because this is simply part of the responsibility that comes with contributing. Fixing follow-up issues, investigating regressions, and iterating on previous changes is a normal and expected part of the process</p>
I'm sharing this to make one thing clear: introducing a bug does not make you a bad contributor, but ignoring it may</p>
Dealing with Reviews and CI</a></h2>
So you sent your first pull request - great job, that's a big achievement by itself! After that the CI will automatically start, it will build compiler, check tidy</code>, style, all tests, and maybe something else, it took approx. about hour, so.. be ready</p>
Also, if your CI fails, don't be afraid of it. It's perfectly normal, even for the most skilled top-tier Rust contributors. It's so easy to miss something in the CI checks and cause a failure. Our bot will politely tell you exactly what failed and most likely tell you how to fix it. Just force-push the fix and move on. We all see it daily and fail CI ourselves :3</p>

Now let's talk about what happens during review. You might worry: "Will strict people come and nitpick every little thing in my code, just to embarrass me?" Absolutely not. If the review process seems picky, keep in mind it's not personal. Reviewers are not judging you as a person; they're focused on the code. When someone asks you to fix a bunch of small issues, it's only to improve the project, not to discourage you</p>
As a newcomer, you might not immediately understand what a reviewer is asking for. That's okay. Feel free to ask for clarification. Just comment on the review saying something like "Could you help me understand this comment?" Everyone was new once, and they will help you understand the feedback</p>

Sometimes review comments can sound a bit harsh or blunt. Remember, that's usually just a tone issue - it's much easier to criticize code than to criticize a person. Try to interpret comments as suggestions on the code. If something stings, don't take it personally. You and your contribution matter to us, and we want to see you succeed</p>
Imagine you get a review and they ask you to make a change, but you're not sure what they mean. Perhaps you've been staring at your editor for days, too intimidated to ask, and you feel like you've lost all sense of direction. Or maybe you immediately reach out and ask a reviewer for a clarification on something really simple, and they point out "oh, it was literally 5 lines above your current code." Both situations happen to everyone</p>
The balance is: try solving it yourself first, but not at the cost of burning out. If you spend a reasonable time trying to figure out the requested change and still can't do it, that's okay. Just go back to the reviewer and explain what you tried and where you're stuck. For example: "I tried inserting this line here and running the test, but it still fails with X. I'm not sure how to fix it." This shows you made an effort, and trust me, reviewers deeply appreciate when you explain your attempts. It makes it easier for them to help you and keeps the collaboration going smoothly</p>
Useful resources</a></h2>


https://rustc-dev-guide.rust-lang.org/</a> - your primary handbook for everything compiler related</p>
</li>

https://forge.rust-lang.org/</a> - policies, procedures, and team information</p>
</li>
</ul>
Random tips</a></h2>
They are not necesessary, but you may found them useful, they initally were in text, but I decided factor them out to its own chapter</p>
Tip 1</a></h3>
there are compiler flag, that might help you figuring out where error message was created -Ztrack-diagnostics</code>, it will show you a line of code in compiler where error was actually created (it's not always 100% helpful, but very likely would be a good starting point, I found this one very useful at my start)</p>
here is an example</p>
warning: function `is_maybe_transmutable` is never used
--> /home/gh-Kivooeo/test_/src/main.rs:6:12
|
6 |     pub fn is_maybe_transmutable<Src, Dst>()
|            ^^^^^^^^^^^^^^^^^^^^^
|
= note: -Ztrack-diagnostics: created at compiler/rustc_passes/src/dead.rs:1113:18
</code></pre>
as you can see above, there is a note with a specific place</p>
Tip 2</a></h3>
Once you have a working build, you can save hours of recompilation time by using the --keep-stage</code> flag. For example</p>
./x b --keep-stage 1</code></p>
This tells to x</code> to reuse the already-compiled stage 1</code> compiler when you make changes to later stages. Sometimes you still need a full rebuild, but for most iterative work this flag is a lifesaver</p>
Small conclusion</a></h2>
Starting to contribute to Rust isn't about genius, it's about curiosity and persistence. You don't have to know the entire codebase. You learn, ask questions, and take small steps</p>
That was the first part. I hope it helped you at least a little and dispelled some of your fears</p>
In the next part, I want to take a real issue and walk through the process from start to merge, showing the entire process in detail</p>


The `if let guard` stabilization path
2026-01-25T00:00:00+00:00
Hi all!</p>
In this blog post, I'm going to talk about a feature I've been working on stabilizing</p>
The original tracking issue</a> was created more than 7 years ago</p>
I've been using Rust for less than 7 years, so I’ll relay what I’ve heard: the feature was stabilized at first, but some drop-order bugs appeared, and it was quickly destabilized. I guess it was then abandoned for a long time, currently, all the drop order bugs have been fixed, and it works correctly</p>
I encountered some code where I tried to use if let guard</code> and then compiler says</p>

hey, that's not stable, what are you trying to do here?</p>
</blockquote>
and I was like</p>

eeh, what do you mean not stable, this is so obvious and... simple, like, how is this different from an if guard</code></p>
</blockquote>
After that, I started investigating this feature, this was at the very beginning of my contributing journey somewhere around end of April</p>
And I got a lot of help from another Rust team member est31</a>, who, not long before I started looking into this, had finished stabilizing let chains</code> which was a major stabilization for Rust and one of the most requested features overall</p>
As you can tell from the post's title, it's about the if let guard</code> feature, which I think is a very pretty one :3</p>
What is this feature even about?</a></h3>
This is a pretty straightforward feature at first sight, I mean very straightforward, it's basically allows you to use let</code> patterns in match guards, like this</p>
let x = "42";
let y = Some(2);

match x.parse::<i32>() {
    Ok(s) if let Some(y) = y => (),
    Ok(s) => (),
    _ => (),
}
</code></pre>
This simple snippet shows what the feature does - nothing complicated, right? So roughly without this feature (there are many ways to rewrite it in Rust, I just pick one that is closest to the code above and what I'd use)</p>
let x = "42";
let y = Some(2);

match x.parse::<i32>() {
    Ok(s) => {
        if let Some(y) = y {
            // first branch
        } else {
            // second branch
        }
    }
    _ => (),
}
</code></pre>
Personally I don't like this, I never liked this, just because there is cases where you really don't want to create a block in match arm and just return value</p>
struct A {
    x: i32,
    y: i32,
    related_points: Option<Vec<A>>,
}

fn main() {
    let a = A {
        x: 2,
        y: 3,
        related_points: Some(vec![]),
    };

    let x = Some(42);

    match x {
        Some(x)
            if let A { related_points, .. } = a
                && let Some(points) = related_points => points.len()
        _ => 1,
    };
}

</code></pre>
So, currently you are forced to write a block like this</p>
match x {
    Some(x) => {
        if let A { related_points, .. } = a
            && let Some(points) = related_points
        {
            points.len()
        } else {
            1
        }
    }
    _ => 1,
}
</code></pre>
As I said before, I don't like this, like, completely</p>
As you might have already seen, if let guard</code> could use let chains</code>...</p>
Let chains</a></h3>
Yes, you get it right, this feature is fully compatible with let chains</code></p>
let chains</code> are actually one of my favorite Rust features, even though I started learning Rust only few years ago, I can definitely tell that let chains</code> were my most used feature since then, I do really love</em> patterns and hope you too!</p>
So back to let chains</code> in if let guard</code>, you might be wondering, what's so special about them?</p>
Here’s the answer: let chains</code> were originally restricted to Rust 2024+ editions, so using them in edition 2021 (or earlier) would give an error</p>
error: let chains are only allowed in Rust 2024 or later
 --> src/main.rs:4:8
  |
4 |     if let Some(x) = Some(42) && x.is_positive() {
  | 
</code></pre>
This will not work as we just tried above, but you already have seen the possibility of using let chains</code> in if let guard</code></p>
A few questions might come to mind:</p>

Does that mean that if let guard</code> going to be stabilized in edition 2024+?</li>
Or does it mean that I could use if let guard</code> in all editions, but using let chains</code> in if let guard</code> will be restricted</li>
</ol>
Sooo... my answer will be pretty short and direct: using let chains</code> in if let guard</code> will be allowed in all editions, which means</p>
fn main() {
    match 0 {
        _ if let Some(x) = Some(42) && x.is_negative() => println!("wow!"),
    }
}
</code></pre>
This code will work perfectly fine in all editions even though it contains let chains</code></p>
Important note here:</p>
Currently, if you try to run this code in edition 2021 or lower, it will give you an error, about let chains</code>, just because, when we are parsing if let guard</code> in compiler we do have a check</a> for let chains</code> to gave such error,</p>
if has_let_expr(&cond) {
    let span = if_span.to(cond.span);
    self.psess.gated_spans.gate(sym::if_let_guard, span);
}
</code></pre>
But don't worry, this will be deleted with stabilization, it's fine that it doesn't work now, it will work as stabilized</p>

This is snippet from my code that I wrote to fix a diagnostic problem using both of these features, we are using a lot of unstable features in compiler so which is why I was able to do this,</p>
Btw, if you aren't comfortable with understanding this code, which is 100% fine, I'm not waiting for the reader to be a rustc developer, just try to see the differences in form itself, the semantics are pretty much the same</p>
The problem was that an Op::AssignOp(assign_op)</code> branch already existed and extending it for this new check would have been messy, since it wasn't just a few lines, so it would have dramatically bloated the original branch, the solution was to create a separate branch and do all the checks right in the match guard:</p>
Op::AssignOp(assign_op)
    if assign_op.node == hir::AssignOpKind::AddAssign
        && let hir::ExprKind::Binary(bin_op, left, right) = &lhs_expr.kind
        && bin_op.node == hir::BinOpKind::And
        && crate::op::contains_let_in_chain(left)
        && let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) =
            &right.kind
        && matches!(path.res, hir::def::Res::Local(_)) =>
{
    // give a nice user friendly error here :3
}
</code></pre>
Actually, for those who wonder how the same code will looks without all this stuff is... this...</p>
Op::AssignOp(assign_op) => {
    if assign_op.node == hir::AssignOpKind::AddAssign {
        if let hir::ExprKind::Binary(bin_op, left, right) = &lhs_expr.kind {
            if bin_op.node == hir::BinOpKind::And {
                if crate::op::contains_let_in_chain(left) {
                    if let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) =
                        &right.kind
                    {
                        if matches!(path.res, hir::def::Res::Local(_)) {
                            // give an nice user friendly error here :3
                        }
                    }
                }
            }
        }
    }
}
</code></pre>
This is far from perfection! So please use both of these nice features to get closer to it ^^,</p>
When this feature will be out?</a></h3>
Actually, in perfect scenario, I'd say that this feature will be stable at 1.95, which is very optimistic. There is only one blocker left: documentation, so as far as I can tell, it will be FCP'ed and merged after the documentation is merged, in less optimistic scenario I think it will be ready to 1.96, but, to be honest both of these scenarios are very close and mostly important is very realistic, because all the concerns about drop order have been resolved, there is nothing blocking it</p>
FAQ section</a></h1>
This section will answer some of the questions that might come up in your head</p>
Why are let chains in if let guard stable on all editions?</a></h3>
That's a really good question! It's hard to say with complete confidence since I wasn't working on the original let chains</code> stabilization and I'm not deeply familiar with that part of the compiler. But from what I've learned from the team: let chains</code> in if let guard</code> don't suffer from the drop order issues that affect regular if chains</code> because there's no else</code> block like in if let</code> has that can cause scoping complications.</p>
To stabilize let chains</code> for Edition 2024, the if_let_rescope</code> feature was introduced to fix drop order behavior in contexts with else</code> blocks. Match guards never had this problem—they're just boolean conditions without an else</code> branch, so temporaries already had predictable scoping. Since if let guard</code> already behaves correctly without needing the rescoping fix, it works consistently across all editions.</p>
What was the drop order bug that was fixed?</a></h3>
Well, I can't tell about previous stabilization, since not much is known about it, but I can speak about current one</p>
So in current stabilization, right after it was FCP'ed and I had fixed all (30+) the last nits, and it was sitting in the queue to be merged, dianne</a> raised a very good point with drop order,</p>
I will leave her comment</a> here, just in case someone wants to see it for themselves, but I will explain this a little, honestly this comment is pretty well written as it, but here's the problem:</p>
match SignificantDrop(0) {
    x if let y = SignificantDrop(&x) => {}
    _ => unreachable!(),
}
</code></pre>
x</code> drops before y</code> which is not obvious and maybe incorrect sometimes, and another case shows the actual problem of inconsistent drop order pretty well</p>
match [LogDrop(o, 2), LogDrop(o, 1)] {
    [x, y] if let z = LogDrop(o, 3) => {}
    _ => unreachable!(),
}
</code></pre>

First, let me explain how to read this, it exactly show drop order by numbers, so LogDrop(o, 1)</code> will drop first, LogDrop(o, 2)</code> second and so on</p>
</blockquote>
So here, it will drop everything in the following order y</code> -> x</code> -> z</code>, which is also not correct, you would expect right to left drop order, now, thanks to dianne's efforts, it works as intended and expected: z</code> -> y</code> -> x</code></p>
match [LogDrop(o, 3), LogDrop(o, 2)] {
    [x, y] if let z = LogDrop(o, 1) => {}
    _ => (),
}
</code></pre>

This behavior was fixed by dianne in this pull request</a></p>
</blockquote>
What is the current drop order behavior?</a></h3>
So yes, as you might have seen above, the drop order is correct and right to left order</p>
match [LogDrop(o, 5), LogDrop(o, 4)] {
    [x, y]
        if let z = LogDrop(o, 3)
            && let w = LogDrop(o, 2)
            && let v = LogDrop(o, 1) => {}
    _ => (),
}
</code></pre>
This is consistent and stable, so there is nothing to worry about. There was also a bug with pin!()</code> that was found also during the limit testing of if let guard</code> by theemathas</a>, so this bug looked like this and it wasn't necessarily a bug in the if let guard</code>, but let chains</code> one</p>
    if let x = LoudDrop("0")
        && let y = pin!(LoudDrop("1"))
        && let z = pin!(LoudDrop("2"))
        && let w = LoudDrop("3")
    {}
    // 3
    // 0
    // 2
    // 1
</code></pre>
And once again, this is not what you would expect, but yeah, on current stable version this is already fixed and working as intented</p>

Also was fixed by dianne here</a></p>
</blockquote>
Performance question</a></h3>
Q: Does this compile to the same code as using a block, and/or does it have any overhead from creating a block with an if let</code>?</p>
Well, this is a reasonable question and concern, but answer is no, both of these code examples compile to the same assembly, have the same semantics, and the same drop order/scope behavior. So yeah, I'd say they are identical</p>
    match 0 {
        _ if let Some(new_x) = Some(2) && new_x > 150 => x = new_x,
        _ => x = 1,
    }
</code></pre>
    match 0 {
        _ => {
            if let Some(new_x) = Some(2) && new_x > 150  {
                x = new_x;
            } else {
                x = 1;
            }
        }
    }
</code></pre>
Shadowing</a></h3>
Quick quiz: what will this print?</p>
match Some(4) {
    x if let Some(x) = Some(2) && let Some(x) = Some(5) => println!("{x}"),
    _ => panic!()
}
</code></pre>
if you answered 5, you are correct, so yeah, it will just shadow all previous x</code>'s</p>
Irrefutable Patterns</a></h3>
The compiler will correctly understand if a pattern is irrefutable, so like in this example</p>
    match Some(()) {
        Some(x) if let () = x => {}
        _ => {}
    }
</code></pre>
It will give you a nice warning :3</p>
warning: irrefutable `if let` guard pattern
  --> src/main.rs:41:20
   |
41 |         Some(x) if let () = x => {}
   |                    ^^^^^^^^^^
   |
   = note: this pattern will always match, so the guard is useless
   = help: consider removing the guard and adding a `let` inside the match arm
   = note: `#[warn(irrefutable_let_patterns)]` on by default
</code></pre>
Conclusion & Personal Note</a></h1>
I don't like conclusions because they usually just repeat everything you already read, so I'll keep this short: the feature is nice, the blockers are resolved, around 1.95 hopefully!</p>
That's all! If you like what I'm doing and want to ✨ support ✨ my work, I have a sponsor page</a>. I also just updated it with information on how you can support me without crypto (using crypto, yes xD)</p>
Working on long-running compiler takes time and focus - which brings me to a small personal note</p>
I'm planning to move to my partner's city soon. While I have the funds saved up, any support to make this transition smoother and less stressful would mean the world to me</p>
With heartfelt thanks to the Rust community!</p>


First post
2025-12-25T00:00:00+00:00
Hi, last time I wrote about uncertainty</a>. This time, I want to write about what came after. Here's an update on my journey after that post - the progress, the difficulties, and where I ended up</p>
There, where it all ended last time</a></h2>
After my last post, I received an overwhelming amount of support - both in comments and private messages. Thank you all so much for that. Several people also reached out with job offers, which I genuinely appreciated</p>
But none of them fit my situation in the end. Some were with established companies abroad that couldn't cover relocation costs because of sanctions - something I currently can't afford on my own. Others were in areas like crypto and web3: fields I respect, but not ones where my skills or interests truly lie</p>
So my only sponsor all this time was my mom - in fact, it's hard to say how much work she did for Rust without even realizing it</p>
The place where stars align</a></h2>
Almost two months after my original post, I was added to the compiler team</a>. In the four months since my post, I've been working on the compiler steadily - usually 1-3 hours a day, though some bugs demand more. Recently, there was one day when I didn't open GitHub at all because I'd spent the day before and almost half the night until 4 am trying to understand this bug</a></p>
When I finally fell asleep around 6 am and woke up about 10 hours later, I decided to take a break for the day. It's funny - I don't remember any other day when I didn't open GitHub</p>
Even on the day I was drafted into the army (a whole story of its own), I spent the morning reviewing a pull request</a> - literally just a few hours before they came for me. They took me to the distribution center, then brought me back home at 9 pm because I "didn't suit them"</p>
And I'm pretty sure that later that night, I went back to do some other reviews. If they hadn't brought me back, I would have returned to Rust in a year LMAO</p>
The sum of all that happened</a></h2>
Let's talk about how the numbers have changed since the last post, I don't like this kind of metrics, but that's all we have I guess. At the time of writing, thanks.rust-lang.org</a> shows 171 contributions, compared to 88 in my last post - a pretty big jump</p>
Despite that jump, my ranking didn't move as dramatically - from 360th to 235th all-time. I've noticed that the higher you climb, the slower it gets :) I probably won't reach the top 200 this year, but looking back at the progress - from my very first pull request to these numbers - still feels really good</p>
The idleness that never rest</a></h2>
As you may have guessed, I was technically unemployed all this time - though I wouldn't call it that myself</p>
So what did I decide by the end of the year? Considering I need relatively little to live on (about $250-300 a month, since I don't pay rent), I decided to return to my previous job teaching IT to children. I left this job at the end of last school year, but it's a good fit for my situation</p>
The job takes only about two days per a week. The salary of $550–600 gives me enough to live on and even save a little for things I enjoy, plus plenty of time to work on the compiler. And the job itself:</p>


I genuinely like it</p>
</li>

helps me take my mind off code and remember real life exists - children are the best guide for that</p>
</li>

removes financial stress</p>
</li>
</ol>
The only downside is that it's not scalable in the conventional sense. But since I'm not chasing big numbers - just stability and the opportunity to keep contributing - I think this is a good solution</p>
The Unclenching</a></h2>
This will be the last chapter before Q&A</p>
It's the end of the year now, and I want to say this has probably been the most emotionally difficult year for me - the army, finances, work, potential relocations, instability</p>
In about three weeks I'll turn 21</p>
For now, I think I had found an opportunity to work on what I like and make it financially stable without sacrificing the part of myself that wants to work on Rust</p>
For those who've asked - I've set up a sponsor page</a> with the options currently available to me, only crypto :(</p>
Thank you all for this year. Happy New Year, everyone!</p>
To read the stars, first learn the dark</a></h2>
Q: I want to contribute to the compiler, but it's overwhelming. Where do I start?</p>
A: Don't think about the size - just find something specific that interests you and start there</p>

Q: But I don't know anything. How can I make changes?</p>
A: Search the codebase for keywords related to what you're looking for. Most of the time, something similar already exists - variables, functions, comments, anything that gives you context. If you're still stuck, please, don't hesitate to ask in Zulip. People are helpful</p>
And here's slightly controversial advice: you can use LLMs to understand code snippets. If you're staring at a function and have no idea what it does, an LLM can usually explain it. Ask "why does this work?" or "what is this doing?" But - and this is critical - use it to understand</em> code, not to write</em> code for you. Don't submit generated pull requests that you don't fully understand. That wastes reviewers' time and doesn't help you learn</p>

Q: What did you learn about sustaining motivation over months of unpaid work?</p>
A: In my case, staying motivated was probably the least of my problems, to be honest. Here are some reasons (not in order of importance):</p>


the tasks are very interesting</p>
</li>

there is a lot of room for learning and development</p>
</li>

I love Rust</p>
</li>

the community is incredibly cool, and it's a pleasure to work with them</p>
</li>

it's just a hobby among my other hobbies that I also devote time to, such as studying other sciences, creativity, or games</p>
</li>
</ol>

Q: Any mistakes you made early on that you'd warn others about?</p>
A: Yes, and it wasn't even about code - it was about communication and the language barrier</p>
Early on, I was using LLMs heavily to write my comments. Then I got a private message: "Hey, I noticed you write strangely. Don't be afraid to make mistakes or write in your own words - just don't rely on LLMs so much." A couple days later, another reviewer commented that my writing seemed sloppy</p>
I'm grateful for that first message. Since then, I've stopped using LLMs for writing and only occasionally use translators for specific words or a grammar checker. It's better to write imperfectly in your own voice than perfectly in an AI's</p>

Q: What would you tell someone else stuck in a difficult location/situation who wants to do meaningful work?</p>
A: It really depends on your situation. I had financial support from my mom, which gave me space to contribute full-time. If you don't have that safety net, my honest advice is: stabilize your life first. Big projects like Rust aren't going anywhere - they'll still be there when you're ready. Your personal situation matters more</p>
That said, if you can't wait or don't want to - even 30 minutes to an hour a day adds up. Consistency matters more than volume. Just be realistic about what you can sustain</p>

Q: How did you deal with the uncertainty and financial stress mentally?</p>
A: The hardest part was feeling like I was consuming resources - relying on my mother's support - without creating anything materially useful in return. As someone who values family responsibility, that guilt slowly kept growing. What helped was looking at my actual results. It reminded me that the work was meaningful - even if it didn't pay the bills. That kept me from giving up</p>

Q: What kept you going when things looked hopeless?</p>
A: Take real breaks. Step away, recharge, and come back fresh. And when I say "real breaks" - I mean actually disconnect. I kept checking GitHub even during mine, which defeated the purpose</p>

Q: How do you know when to push through vs. take a break?</p>
A: Honestly, this is the hardest question because it requires self-awareness, and everyone's different. For me, the key signal is autopilot - when I catch myself going through the motions without actually thinking, when I'm staring at code but not really seeing it. That's when I know I need to stop</p>

Q: The teaching job solution - how did you figure out what "enough" money/time looked like?</p>
A: I just looked at the numbers. I tracked how much I actually spend each month - bills, food, personal stuff - and it came to around $250-300</p>
For time, I knew that even an hour a day would be enough for compiler work if I stayed consistent. Working two days a week at the teaching job leaves me plenty of time while still providing the stability I need to contribute regularly</p>

Q: What surprised you about the response to your first post?</p>
A: Two things, actually</p>


people who tried to spread negativity in the comments</p>
</li>

the overwhelming support. I really didn't expect so many people to reach out with genuine encouragement and offers to help. The community response was beyond anything I imagined</p>
</li>
</ol>

Q: Any advice on asking for help vs. going it alone?</p>
A: Learn to recognize the difference between "I need more time to figure this out" and "I actually need help from someone who knows this area." Try to solve things yourself first, but don't waste days being stuck when someone could answer in five minutes. It's a balance, and it takes practice to find it</p>

Q: What does "звёзды все принадлежат богам" means on your profile?</p>
A: Ah, this is a line from the song of the same name</p>

А звёзды все принадлежат богам
И их не поймать, они не падают к ногам</p>
И не уместен торг по рукам</p>
Птице - небо, человеку - смерть</p>
</blockquote>
It translates roughly to something like this</p>

The stars remain in the keeping of the gods
Uncatchable, they offer no descent to our level</p>
There can be no bargains in such things</p>
A wing has the air; a life has its grave</p>
</blockquote>
Everyone will interpret this in their own way, so I'll leave the meaning open. But yes - "the stars all belong to the gods" is the direct translation</p>

Q: What is the main conclusion you have come to?</p>
A: If I learned anything this year, it's that consistency beats intensity - and that meaning is sometimes enough to keep going. That even small but steady steps are better than rare but wide ones</p>


Sponsor
2025-12-12T00:00:00+00:00
Hi!</p>
I am a member of the Rust compiler team. Over the past ten months, I have made over 400 contributions, including fixing bugs, improving diagnostics, stabilising features, reviewing pull requests and mentoring new contributors</p>
I care deeply about Rust, and I plan to continue investing a lot of time in improving the compiler, the test suite and the experience of contributors</p>
Why support me?</a></h2>
Your support enables me to dedicate more focused time to compiler development and mentoring. I am transitioning from part-time teaching into a position related to Rust and also moving to another city. Any additional support would make this transition smoother and enable me to maintain my focus on long-term contributions</p>
If you have found my work, blog posts, mentoring or compiler improvements valuable, this is one way you can help me to continue doing them</p>
Why only crypto?</a></h3>
I'm in Russia, where:</p>


GitHub Sponsors doesn't work</p>
</li>

International payment systems are blocked</p>


Bank transfers are nearly impossible</p>
</li>

Grant programs can't send funds here</p>
</li>
</ul>
</li>
</ul>
At the moment, cryptocurrency is the only viable option for receiving support</p>
How to support?</a></h3>
SOL: Ao3QhbFqBidnMnhKVHxsETmvWBfpL3oZL876FDArCfaX</p>
ETC: 0xe1f27D7B1665D88B72874E327e70e4e439751Cfa</p>
If you really want to support financially but don't have crypto</a></h3>
All you need is</p>


visit this website</a>, no registration or anything needed</p>
</li>

Then choose second tab "Buy/Sell Crypto"</p>
</li>

Here you select</p>

USD or EUR on top</li>
SOL on bot</li>
and paste my wallet in here</li>
</ul>
</li>

Confirm payment and that's it! :3</p>
</li>
</ol>
You can see all donations here</a></p>
Other ways to help</a></h3>
Whether you choose to support me financially, follow my journey or contribute to Rust yourself, I truly appreciate it. Being part of this community means a lot to me!</p>


About Me
2005-01-19T00:00:00+00:00
Hi, my name is [DATA REDACTED], known as Kivooeo, working as a compiler engineer on Rust Compiler Team on a volunteer basis daily!</p>
Don't know what to say here, but I'm sure that this page will grow in size over time :3</p>

kivo's blog

Part 2: Tackling an `A-diagnostics` issue

Part 1: Tackling an `E-needs-test` issue

So You Want to Contribute to Rust

The `if let guard` stabilization path

First post

Sponsor

Why only crypto?</a></h3> I'm in Russia, where:</p> GitHub Sponsors doesn't work</p> </li>

About Me