Warning

This post was published 31 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Tracing a lint's reasoning

Over the years I have learned an important lesson about lints: Whenever I encounter a warning that I don't think is true, I should step away for five minutes, stretch and make a fresh cup of tea, and then just read the code carefully. It is extremely rare that the lint warning is wrong.

Recently I encountered a lint warning for a piece of code whose outline looks like this:

loop {
  let did_proc = false;

  if some_condition_1 {
    did_proc = true;
    // .. other stuff ..
  }

  if some_condition_2 {
    did_proc = true;
    // .. other stuff ..
  }

  if some_condition_3 {
    did_proc = true;
    // .. other stuff ..
  }

  if !did_proc {
    break;
  }
}

It's telling me that the did_proc = true's are never read. The "other stuff" sections contain a bunch of continue and breaks. So what I'm thinking is that when the did_proc = true has been run, the compiler reasons that all branches lead to either a break or a continue. However, there's one path in each of these sections that has neither a break or continue. So I'm wondering if the compiler is able to deduce that this path can't happen.

As much as I love lints, this is one of the things that can become a little bit of a time-sink for me. Is there any way to see how the lint is "reasoning" (to get a hint about why it is triggering?). I have no idea how this would look, but I'm curious to know how people track down terse lint warnings whose cause isn't immediately obvious.

---

While writing this, I think I figured out why it's issuing that warning -- and if so it is indeed correct. But my question still stands -- because this isn't the first (or, I suspect, last) time this happened.

2 posts - 2 participants

Read full topic

🏷️ Rust_feed