Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

-Zpanic-in-drop=abort for rustc + tools #89269

Open
Mark-Simulacrum opened this issue Sep 26, 2021 · 3 comments
Open

-Zpanic-in-drop=abort for rustc + tools #89269

Mark-Simulacrum opened this issue Sep 26, 2021 · 3 comments
Labels
I-compiletime Issue: Problems and improvements with respect to compile times. WG-compiler-performance Working group: Compiler Performance

Comments

@Mark-Simulacrum
Copy link
Member

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.

@Mark-Simulacrum Mark-Simulacrum added the WG-compiler-performance Working group: Compiler Performance label Sep 26, 2021
@Mark-Simulacrum
Copy link
Member Author

@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
Copy link
Member

the8472 commented Sep 26, 2021

To ask the obvious, could the compiler be built with -Zbuild-std?

@Mark-Simulacrum
Copy link
Member Author

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.

@Mark-Simulacrum Mark-Simulacrum added the I-compiletime Issue: Problems and improvements with respect to compile times. label Jan 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-compiletime Issue: Problems and improvements with respect to compile times. WG-compiler-performance Working group: Compiler Performance
Projects
None yet
Development

No branches or pull requests

2 participants