You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This flag was added in #88759 and showed good performance and code size benefits for rustc. It would be nice to see if we can land those benefits, both to get some experience with aborting instead of unwinding panics in destructors (e.g., what goes wrong? any painful patterns?) and to carry forward those performance and size wins.
This flag is currently restricted to being the same across the whole crate graph though, which means we'd not be able to do this for rustc only since it would also affect std's destructors (which would be a user-visible change we don't want). Opening this issue to see if there's a way we can work around this.
@Amanieu you mentioned in #88759 that the reason for being the same across all crates is that Box<dyn Any> is assumed to not unwind on drop. (Presumably this affects other trait objects too).
Can we avoid that assumption, or otherwise workaround the limitation for rustc in particular? If there's no forseeable way, then it probably makes sense to just close this.
Rustbuild could do that, yeah; the compiler could have its own standard library that's separate from the one we distribute (e.g., so that we could run PGO for the compiler on that std, this option). But in practice, I'd really prefer to avoid a duplicate standard library since it both complicates our build system in a somewhat non-trivial way and encourages us to further diverge, which I'd prefer to avoid at least for now.
Activity
Mark-Simulacrum commentedon Sep 26, 2021
@Amanieu you mentioned in #88759 that the reason for being the same across all crates is that
Box<dyn Any>is assumed to not unwind on drop. (Presumably this affects other trait objects too).Can we avoid that assumption, or otherwise workaround the limitation for rustc in particular? If there's no forseeable way, then it probably makes sense to just close this.
the8472 commentedon Sep 26, 2021
To ask the obvious, could the compiler be built with -Zbuild-std?
Mark-Simulacrum commentedon Sep 26, 2021
Rustbuild could do that, yeah; the compiler could have its own standard library that's separate from the one we distribute (e.g., so that we could run PGO for the compiler on that std, this option). But in practice, I'd really prefer to avoid a duplicate standard library since it both complicates our build system in a somewhat non-trivial way and encourages us to further diverge, which I'd prefer to avoid at least for now.