[tialaramex]

I get why they'd panic, but why have enough segfaults that you noticed? So, I went and read the code.

Zuban seems to have a bunch of scary "I'm not sure if this is correct" unsafe blocks, which to me would be a red flag. I mean, it's better that there's a comment expressing the doubt, but my experience is that if you're not sure whether it's correct, it's probably not correct.

[estebank]

While acknowledging the risk of causing a pile-on (which I don't want!), would it be possible to have a link to them or a description of what the unsafe blocks accomplish? I'm intrigued if they are for performance or API ergonomics, if they are due to limitations of the borrow checker, the stdlib or crate dependencies.

For anyone reaching for unsafe, there are in many cases either an existing API (split_at_mut comes to mind). For others, using zero-copy or bytemuck instead of unsafe is a good idea too.

None of that is to say "never write unsafe", unsafe existing is pretty much one of the reasons for Rust to be :)

[tialaramex]

I skimmed these, so this is nothing close to a survey, much less a comprehensive review of the software, however

For example in crates/zuban_python/src/file/diagnostics.rs:

"TODO this unsafe feels very wrong, because a bit lower we might modify the complex/ points."

or crates/zuban_python/src/database.rs:

"Points are guarded by specific logic and if they are overwritten by something that shouldn't it should not be that tragic."

I saw nothing where I was like "ZOMG this is definitely busted" but I definitely did not get the robust "Oh, I see now why this is correct" that I like from a good unsafe rationale comment, and these aren't tiny things like the small unsafe bit twiddling transmutes which are probably either actually correct or in any case will do what you expected at compile time and so any surprises are priced in without a rationale text.