It's surprising this bug went unnoticed for so long, but at least it's easy to fix, since it's not a bug with the type system itself; it's just a bug in the compiler. The compiler should always have been rejecting that code according to lifetime rules of Rust's type system, so the fix is to just make it reject the code, rather than having to change the fundamental rules of lifetimes.

This is remarkable but not super unusual. There are more than 100 issues labeled unsound currently. Some are long standing but from what I understand the new trait solver will unblock fixes for some of them (but probably not the one in OP).

Perhaps ironically, AI-based searching of the Rust compiler for bugs is likely to find more of these, pushing Rust closer and closer to the point of complete reliability.

The eventual formalization of Rust and a creation of a formally proven compiler is presumably going to be the end point of this process.

I feel like these things get waved around as gotchas without any sense for whether any real code is impacted.

It will be interesting to see if fixing this bug actually causes any crates to not compile.

Type systems are hard! Check out https://counterexamples.org/

I gave it a quick scan for Rust examples; there are 11 samples among the following pages:

  https://counterexamples.org/eventually-nothing.html
  https://counterexamples.org/mutable-matching.html
  https://counterexamples.org/selfishness.html
  https://counterexamples.org/scope-escape.html
  https://counterexamples.org/nearly-universal.html

The first thing I always look for is mutability (combined with some other tricky feature), e.g. "Now it's a Just(3):Maybe<Int>, now it's a Nothing:Maybe<Int>, now it's a Nothing:Maybe<String>."

I wonder if TFA's example could be reproduced without mutability.

Took me a good couple minutes to wrap my head around. Man, what a nasty bug. I guess this specific use-case is rare. Time to see if any of the big libs are affected...

I just wish Rust handled out of memory more gracefully like a normal error.

I'm sure we'll get more of those on other languages / frameworks too. I tend to believe that it's for good

The emotional reactions to this stuff are so weird. Yeah, software has bugs, what a surprise. That doesn't mean that static safety is useless or that we should all just continue YOLOing stuff in C.

Worked on a variance-related lint once and the scary part is how rarely anyone writes down variance by hand, so bugs there just sit untested for a decade.

The question is. If rust used rust would that have prevented this?

The heart of the matter:

  struct Q<T: 'static>(Option<T>);

  impl<T: 'static> Drop for Q<T> {
    fn drop(&mut self) {
        // Code in here has access to a non-'static &String
        // but assumes that it's a &'static String
    }
  }

  fn main() {
    let l = String::new();
    let mut q = Q(None);
    q.0 = Some(&l);
  }

I wonder if the certified compiler for safety critical uses (edit: Ferrocene) has the same issue.

There is a collection of these someplace. Rust is better but it'll never be perfect, news at 10

What the hell. This is not the esoteric, crazy, impractical constellation I expected to find with a title like this. The minimal example is so simple and is definitely something you'd easily come across in normal code.

I don't understand how something like this could take so long to be discovered. Pretty crazy stuff.

[flagged]

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[flagged]

[flagged]

so now what? back to c++?

very very good job

Here's the weakness of compiled programs. Does this compiled code have this vulnerability? You have no idea. At least with a VM or interpreter you can scan for vulnerable versions and replace the runtime or the specific library.

With this you have to recompile everything

  JFC
  I have never seen Rust code
  Threw up in my mouth

Inspired by that Rust code.

And a fork fixed it before upstream rust :)

Was this done by LLM? this is a doubt. because recently we are seeing many such bug reports.

wonder what happened to this https://raphlinus.github.io/rust/2020/01/18/soundness-pledge...

I think one social issue I’m seeing is that the Rust community bashes other languages for safety but then glosses over or even completely ignores their own safety risks (see supply chain). I would rather see Rust focus on its actual features without bashing others and maybe start moving away from claiming the gold metal on security. Being less toxic is always a good thing for long term health.