Skip to content

/rust

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

Pluggable panic implementations (tracking issue for RFC 1513) #32837

Open
nikomatsakis opened this Issue Apr 8, 2016 · 22 comments

Comments

Assignees
No one assigned
Labels
B-RFC-implemented B-unstable C-tracking-issue P-low T-lang T-libs
Projects
None yet
Milestone
No milestone
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Apr 8, 2016 •
edited by sfackler

Tracking issue for rust-lang/rfcs#1513.

-C panic=abort is now stable, but the ability to create customized panic implementations is still unstable.

@nikomatsakis nikomatsakis added B-RFC-approved T-lang B-unstable labels Apr 8, 2016

@nikomatsakis nikomatsakis referenced this issue Apr 8, 2016

Merged

RFC: Stabilize implementing panics as aborts #1513

@alexcrichton alexcrichton self-assigned this Apr 8, 2016

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Apr 8, 2016

I'm working on an implementation.
@mrpollo

This comment has been minimized.

Sign in to view
Copy link

mrpollo commented Apr 9, 2016

is there a branch we can track? @alexcrichton, thanks!
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Apr 9, 2016

Sure! -- https://github.com/alexcrichton/rust/tree/panic2abort
@ketsuban

This comment has been minimized.

Sign in to view
Copy link
Contributor

ketsuban commented Apr 9, 2016

Will I still need a dummy eh_personality lang item after this goes through? Some googling suggests -Z no-landing-pads was supposed to remove the need for it (for example, this regression report led to this issue which was resolved by this PR) but I only started using Rust for OSdev since it went stable and I've always needed eh_personality even with -Z no-landing-pads.
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Apr 9, 2016

@ketsuban it depends. If you use any library compiled with -C panic=unwind (like the binaries we ship) then you'll need to define eh_personality. If, however, you compile everything with -C panic=abort then you shouldn't need to define a personality.

@alexcrichton alexcrichton referenced this issue Apr 12, 2016

Merged

rustc: Implement custom panic runtimes #32900

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Apr 12, 2016

I've opened a PR for this.

@alexcrichton alexcrichton removed their assignment Apr 12, 2016

@alexcrichton alexcrichton removed the B-RFC-approved label Apr 12, 2016

bors added a commit that referenced this issue Apr 14, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
5702651

bors added a commit that referenced this issue Apr 14, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
82541f0

bors added a commit that referenced this issue Apr 15, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
fcea8fc

bors added a commit that referenced this issue Apr 16, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
3a01595

bors added a commit that referenced this issue Apr 16, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
86988d6

bors added a commit that referenced this issue Apr 18, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
12917a7

bors added a commit that referenced this issue Apr 19, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
2e8f51f

bors added a commit that referenced this issue Apr 19, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
72edc8e

bors added a commit that referenced this issue Apr 19, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
682499f

bors added a commit that referenced this issue Apr 19, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
7312330

bors added a commit that referenced this issue Apr 19, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
8fc05d3

bors added a commit that referenced this issue Apr 20, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
943aa06

bors added a commit that referenced this issue May 5, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
ab568bf

bors added a commit that referenced this issue May 5, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
25eb296

bors added a commit that referenced this issue May 6, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
fb93d8d

bors added a commit that referenced this issue May 7, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
2e19460

bors added a commit that referenced this issue May 9, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
39baa87

bors added a commit that referenced this issue May 10, 2016

@bors
Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakis 
rustc: Implement custom panic runtimes

This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.

[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md

Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.

With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.

Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).

Closes #32837
72ed7e7

@bors bors closed this in #32900 May 10, 2016

@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented May 10, 2016

Ah I should leave this open as the tracking issue

@alexcrichton alexcrichton reopened this May 10, 2016

@phil-opp

This comment has been minimized.

Sign in to view
Copy link
Contributor

phil-opp commented May 13, 2016

The corresponding cargo option is still missing, isn't it? From the RFC:

Add a [profile.dev] option to Cargo to disable unwinding.
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented May 13, 2016

@phil-opp indeed! I was just waiting for a new nightly but now I've got a PR for that as well
@steveklabnik

This comment has been minimized.

Sign in to view
Copy link
Member

steveklabnik commented Jun 4, 2016

cargo PR has landed. should this be closed?
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jun 5, 2016

Nah this is sticking around as the tracking issue for panic runtimes in general. Only the -C panic=abort portion is stable, however.
@aidanhs

This comment has been minimized.

Sign in to view
Copy link
Member

aidanhs commented Jun 12, 2016

Is it intentional/known that anything with plugin = true (i.e. has --crate-type dylib -C prefer-dynamic on the command line to rustc) doesn't work in combination with -C panic=abort?
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jun 12, 2016

@aidanhs I believe that's rust-lang/cargo#2738

@alexcrichton alexcrichton added the T-libs label Jun 21, 2016

@aturon aturon added the I-nominated label Aug 29, 2016

@nrc nrc added the B-RFC-implemented label Aug 29, 2016

@brson brson added the P-low label Aug 29, 2016

@brson

This comment has been minimized.

Sign in to view
Copy link
Contributor

brson commented Aug 29, 2016

The only remaining thing here is the stable mechanism for plugging in new unwinders, which is not a priority.
@Ericson2314

This comment has been minimized.

Sign in to view
Copy link
Contributor

Ericson2314 commented Aug 30, 2016

And which should probably wait for some needs-provides functionality to be implemented or avoided.

@aturon aturon removed the I-nominated label Sep 1, 2016

@sfackler sfackler changed the title Panic as abort (tracking issue for RFC 1513) Pluggable panic implementations (tracking issue for RFC 1513) Sep 7, 2016

@Ericson2314

This comment has been minimized.

Sign in to view
Copy link
Contributor

Ericson2314 commented Oct 4, 2016

Once we have transparently rebuildable std, I'd like to remove the Cargo option from profile. The other profile options do not (to my knowledge) change ABI or semantics so it is inconsistent to put the panic strategy in there. The target spec as per #36647 is a better home for the time being.

@Ericson2314 Ericson2314 referenced this issue Oct 5, 2016

Closed

Abort by default v2 #1765

@japaric

This comment has been minimized.

Sign in to view
Copy link
Member

japaric commented Oct 5, 2016

Once we have transparently rebuildable std, I'd like to remove the Cargo option from profile.

What would be the ideal way to pick the panic strategy then? Would it be something like this? (assuming abort is the default and you want to switch to panic=unwind):

  • executable that depends on std. List std as dependency but enable std's "unwind" Cargo feature
  • executable that doesn't depends on std. Either depend on the panic_unwind crate or some other crate that provides an unwinder.
  • library that wants to indicate that relies on unwinding: depend on std with the "unwind" feature enabled or depend on panic_unwind.

Plus some magic attribute in panic_unwind that causes Cargo to compile everything (std included) with landing pads.
@rkruppe

This comment has been minimized.

Sign in to view
Copy link
Member

rkruppe commented Oct 5, 2016

@Ericson2314

Once we have transparently rebuildable std, I'd like to remove the Cargo option from profile.

How would that work? Leaving aside the issue that it would be a breaking change, per-profile panic strategies are useful: For unit tests you need panic=unwind if you have #[should_panic] tests, but having unit tests is certainly not mutually exclusive with wanting panic=abort in release builds.
@Ericson2314

This comment has been minimized.

Sign in to view
Copy link
Contributor

Ericson2314 commented Oct 5, 2016 •
edited

Here are some ideas:

For the low-level panic ABI stuff (abort/unwinding)

I've been thinking that crates should be able to assert a cfg/scenario formula, and that this formula can be used during dependency solving. [lib]/[bin]/[test]/whatever can each have their own formulas. The panic-abi stuff, since it is part of the target, can be mentioned in those formulas.

Additionally, [bin],[test], etc, since they form a depenency root, could be allowed to specify a default target inline, which could be a diff on one of the built-in defaults.

For high-level strategies

@japaric that's the basic idea, but a proper-needs provides solution should make that slicker. https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst is a proposal for Haskell that basically gives it parameterized packages. For "global/singleton" things panic strategies and log, we need to make a "needer" package for them that must be instantiated exactly 1 way in the install plan.

It's a huge undertaking (Backpack is a PHD thesis), but would be the pinnacle of everything we are trying to do build-system-wise for exotic platform development.

@gz gz referenced this issue Jun 1, 2017

Open

Testing infrastructure #20

@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue label Jul 22, 2017

@geofft geofft referenced this issue May 27, 2018

Merged

Fixes #18 -- call the kernel's BUG macro when we panic #19

@Centril

This comment has been minimized.

Sign in to view
Copy link
Contributor

Centril commented Sep 15, 2018

cc @japaric is this fully done now that #[panic_handler] is stabilized? should we close?
@japaric

This comment has been minimized.

Sign in to view
Copy link
Member

japaric commented Sep 15, 2018

@Centril That depends on whether we want to use this issue to track a stable mechanism for implementing unwinding in no_std (right now you have to use the unstable eh_personality lang item), or if we want to do that in another issue, perhaps in a rust-lang/rfcs issue.
@Centril

This comment has been minimized.

Sign in to view
Copy link
Contributor

Centril commented Sep 15, 2018

@japaric can you raise this on internals perhaps (and close this issue after...)? I'd like to avoid reusing tracking issues and rather keep their scope tightly delimited.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.