← Back to context

Comment by Xirdus

11 days ago

Why would you ever conditionally custom impl Drop? I don't think I've ever seen that pattern, and I can't think of a use case.

12 comments

Xirdus

Reply
jason_oster  11 days ago

Therefore explaining why the bug hadn't been hit in practice for 11 years.

  • Xirdus  10 days ago

    On further reading, the Drop impl is a red herring. The bug is unrelated to Drop. It's there in the repro to show the effects of invalid assignment, but even without impl Drop the bug is still there.

  • Xirdus  11 days ago

    The bug in the OP is about UNconditional impl. And honestly, looks like very standard code, definitely something that could've been written for real. I can't even explain why it passes checks, it clearly shouldn't.

    • dwattttt  11 days ago

      This code, from the bug submission?

        impl<T: 'static + Send> Drop for Q<T> {
      fn drop(&mut self) { if let Some(t) = self.0.take() { KEPT.lock().unwrap().push(Box::new(t)); } }
  }

      The bound on T in the Drop impl means Drop is not implemented for all T, only where T: 'static + Send. Q<T> also having the same bound doesn't make a difference to the Drop impl.

      8 replies →