Skip to content

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

Open

Description

@Mark-Simulacrum

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.

Activity

  1. Mark-Simulacrum commented on Sep 26, 2021

    @Mark-Simulacrum
    MemberAuthor

    @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.

  2. the8472 commented on Sep 26, 2021

    @the8472
    Member

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

  3. Mark-Simulacrum commented on Sep 26, 2021

    @Mark-Simulacrum
    MemberAuthor

    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.

  4. added
    I-compiletimeIssue: Problems and improvements with respect to compile times.
    on Jan 6, 2024
  5. added
    C-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing such
    on Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchI-compiletimeIssue: Problems and improvements with respect to compile times.WG-compiler-performanceWorking group: Compiler Performance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions