This would be useful for dependencies for example, in most circumstances you can safely assume that dependency code doesn't contain compilation errors, so any passes that check for them are just pure and unnecessary overhead.
I don't know how practical this is, I don't have much experience in compiler design (beyond very small and toy compilers).
It's not an identical case, but TypeScript offers this with `skipLibCheck`. Most people use it. It's generally good--until it's really not good and you eat half a day unwinding a deceptively broken dependency.
I don't know if you can toggle it from the front-end, but the Polonius borrow checker includes a "location insensitive" mode which is faster but accepts fewer programs.
After thinking about it, my intuition is that:
- the Vec was passed by value to the function, which in Rust means something different than passing a std::vector in c++ to a function, due to...
- Due to the language semantics, its reference counter remained 1 while inside the function, but decreased to 0 when returning to main, since in Rust if it isn't a borrow (ref) then it's a "steal" - the callee "steals" the Vec completely from the caller. Or something like that.
- Since the reference counter is 0 when returning to main, the Vec is released, akin to calling its destructor if this was C++.
- SOMETHING changed the value of either the internal pointer to the heap inside the stack-allocated Vec (so now it points to garbage), OR something overwrote the Vec's content with some garbage. I'm not sure what that something is, and why would it do that.
I apologize if my explanation/intuition above is garbage in itself, like I said it's been a while since I programmed in Rust.
Edit: formatting
Rust really made me appreciate garbage collection after the number of times I resorted to things like Arc<Box<..>>.
However they are obsessed about performance. They reason for such speedy compile times is that makepad almost has no dependencies.
... What are you doing ? It's definitively unusual.
No it's not, it's extremely common. `Arc<Box<...>>` or `Arc<Mutex<Box<...>>>` or similar is used all the time when you want to share a mutable reference (on the heap, in the case of Box); especially in the case of interior mutability[1]. It's pretty annoying, but I have learned to love the borrow checker (although lifetime rules still confuse me). It really does make my code extremely clear, knowing exactly what parts of every struct is shareable (Arc) & mutable (Mutex).
[1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
[1] https://docs.rs/you-can-build-macros/0.0.14/src/you_can_buil...
[2] https://docs.rs/you-can/latest/src/you_can/lib.rs.html#17-25
