✅ Reproduced — PathString::init is safe but erases the slice lifetime, so the reporter's example compiles and produces a dangling &[u8]. Fix in #30728 marks PathString::init (and the parallel hole in dir_iterator::next()) as unsafe fn with documented outlives contracts, audits ~70 in-tree call sites with per-site SAFETY comments naming the backing allocation, adds compile_fail doctests enforcing the unsafe keyword on all three signatures, and closes the readdir-error fd-leak in the resolver.

Diff is green. CI is red on the pre-existing v8-heap-snapshot.test.ts SIGKILL flake (ubuntu-x64 shard 11/20, hit on three separate builds — unrelated to this PR). Needs a maintainer to merge or retrigger.

also PathString::init erases provenance and fails with MIRIFLAGS=-Zmiri-strict-provenance

Maybe to explain the issue a bit further, looking at https://github.com/oven-sh/bun/blob/main/src/bun_core/string/PathString.rs#L111-L119, we can see that init takes &[u8] a reference to a u8 slice. This references has a lifetime, which is implicit. The unsafe operation erases the lifetime and returns Self which is 'static. This is incredibly bad beacuse it allows for use after free, invalid aliasing, etc.

This is just one example from the codebase, debugging this will be a horrible experience, far worse than what is typical in c/c++ code, especially if your codebase is loaded with such quite horrible mistakes. Rust makes many strong assumtions on it's strong safety model and UB can causes issues in places where you just wont expect them. You are disabeling all of the advantages you claim you get by moving to Rust.

It is highly adviced that every usage of unsafe is properly reviewed in the codebase. Rust is not suited for a 1:1 translation from other languages with different memory managment schemes. Beyond that it's also simply not a good idea.

There is a lot more to say about why all of this is not a good idea, but just to elaborate on the issue it self.

Zig to Rust can be directly translated and Bun isn't a dead project we should stop using. Right?

architector4@AGOGUS:/tmp$ git clone --depth=1 'https://github.com/oven-sh/bun'
Cloning into 'bun'...
…
architector4@AGOGUS:/tmp$ cd bun/
architector4@AGOGUS:/tmp/bun$ find -type f -name '*.rs' -exec grep unsafe {} ; | grep -v '//' | wc -l
13255

This actually makes me mad for reasons I'm still trying to articulate. Maybe it's because I work so hard to take care not to do sloppy things, especially anywhere around using AI agents, and then you see things like this.

I suggest that the maintainers promptly revert, then pause, think, deliberate, and discuss thoroughly with the community, before implementing new policies and procedures surrounding the proper usage of AI code going forward. It just isn't respectful to the 90k+ users who gave a star, and the countless more who adopted Bun or are generally supportive of the project, and reflects poorly on anyone involved in or adjacent to the project. It's bad enough that this was shipped. Every minute this isn't retracted is a new mistake.

Please continue to point out any and all issues in the Rust code. Today, the Rust port is intended to be as close as possible to a 1:1 mapping of the original Zig code - which is the starting point. We are making it better.

This particular issue got a little out of hand with memes, but please do continue to file new issues about any bugs or unsound behavior you find.