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

stabilize #[panic_handler] #51366

Merged
merged 1 commit into from Sep 8, 2018

Conversation

Projects
None yet
@japaric
Member

japaric commented Jun 5, 2018

closes #44489

Update(2018-09-07)

This was proposed for stabilization in #44489 (comment) and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in #44489 (comment)

Documentation PRs:


#[panic_implementation] was implemented recently in #50338. #[panic_implementation] is basically the old panic_fmt language item but in a less error prone (*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.

(*) panic_fmt was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054

Some unresolved questions from #44489:

Should the Display of PanicInfo format the panic information as "panicked at 'reason',
src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".

The current implementation formats PanicInfo as the first alternative, which is how panic messages are formatted by the std panic handler. The Display implementation is more than a convenience: PanicInfo.message is unstable so it's not possible to replicate the Display implementation on stable.

Is this design compatible, or can it be extended to work, with unwinding implementations for
no-std environments?

I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?


Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Jun 5, 2018

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Jun 5, 2018

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:46:05] ..............................................................................i.....................
[00:46:10] ....................................................................................................
[00:46:16] ....................................................................................................
[00:46:22] ....................................................................................................
[00:46:26] ...........i.................iiiiiiiii...................................................
[00:46:26] 
[00:46:26] travis_fold:start:test_ui_nll
travis_time:start:test_ui_nll
Check compiletest suite=ui mode=ui compare_mode=nll (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
---
[00:47:17] ..............................................................................i.....................
[00:47:22] ....................................................................................................
[00:47:26] ....................................................................................................
[00:47:32] ....................................................................................................
[00:47:37] ...........i.................iiiiiiiii...................................................
[00:47:37] 
[00:47:37]  finished in 70.207
[00:47:37] travis_fold:end:test_ui_nll

---
[00:57:06] ....................................................................................................
[00:57:11] ....................................................................................................
[00:57:17] ......................................................................................i.............
[00:57:23] ...............................................ii.iii...............................................
[00:57:28] ...............................................................F...............i....................
[00:57:38] ...............................................................................................i....
[00:57:42] ....................................................................................................
[00:57:48] ....................................................................................................
[00:57:53] ....................................................................................................
---
[00:59:03] failures:
[00:59:03] 
[00:59:03] ---- [compile-fail] compile-fail/feature-gate-panic-implementation.rs stdout ----
[00:59:03] 
[00:59:03] error: /checkout/src/test/compile-fail/feature-gate-panic-implementation.rs:18: expected error not found: #[panic_implementation] is an unstable feature (see issue #44489)
[00:59:03] 
[00:59:03] error: 0 unexpected errors found, 1 expected errors not found
[00:59:03] status: exit code: 101
[00:59:03] command: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/src/test/compile-fail/feature-gate-panic-implementation.rs" "--target=x86_64-unknown-linux-gnu" "--error-format" "json" "-Zui-testing" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail/feature-gate-panic-implementation/a" "-Crpath" "-O" "-Zunstable-options" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-C" "panic=abort" "-L" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail/feature-gate-panic-implementation/auxiliary" "-A" "unused"
[00:59:03] not found errors (from test file): [
[00:59:03]     Error {
[00:59:03]         line_num: 18,
[00:59:03]         kind: Some(
[00:59:03]         ),
[00:59:03]         ),
[00:59:03]         msg: "#[panic_implementation] is an unstable feature (see issue #44489)"
[00:59:03] ]
[00:59:03] 
[00:59:03] thread '[compile-fail] compile-fail/feature-gate-panic-implementation.rs' panicked at 'explicit panic', tools/compiletest/src/runtest.rs:1284:13
[00:59:03] note: Run with `RUST_BACKTRACE=1` for a backtrace.
---
[00:59:03] 
[00:59:03] thread 'main' panicked at 'Some tests failed', tools/compiletest/src/main.rs:498:22
[00:59:03] 
[00:59:03] 
[00:59:03] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" "/checkout/src/test/compile-fail" "--build-base" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/compile-fail" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "compile-fail" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/usr/lib/llvm-3.9/bin/FileCheck" "--host-rustcflags" "-Crpath -O -Zunstable-options " "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" "--gdb" "/usr/bin/gdb" "--quiet" "--llvm-version" "3.9.1\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" "" "--color" "always"
[00:59:03] 
[00:59:03] 
[00:59:03] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[00:59:03] Build completed unsuccessfully in 0:15:16
[00:59:03] Build completed unsuccessfully in 0:15:16
[00:59:03] make: *** [check] Error 1
[00:59:03] Makefile:58: recipe for target 'check' failed

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0dd32d4c
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Jun 5, 2018

Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

At the very least, an issue needs to be opened on the reference. This isn't right for the book, and maybe for Rust By Example. I'm imagining that the embedded docs your WG is working on may want to include it too?

@bors

This comment has been minimized.

Contributor

bors commented Jun 5, 2018

☔️ The latest upstream changes (presumably #51140) made this pull request unmergeable. Please resolve the merge conflicts.

@alevy

This comment has been minimized.

Contributor

alevy commented Jun 5, 2018

This isn't right for the book

@steveklabnik it isn't or is? If not then maybe at least the nomicon? This change basically turns implementing panic from dark magic to fairly accessible and would be really good to have an easy to find reference for it.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jun 5, 2018

I would think docs for this should live in the Rust Reference. I'd like to see using that as, well, the reference for Rust. =)

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Jun 5, 2018

@whitequark

This comment has been minimized.

Contributor

whitequark commented Jun 5, 2018

I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?

Unwinding works on no_std for me for a very long time, we use it in production. Is there anything specific you want to know?

I use unwinding with a custom personality function for the language I designed, but the Rust personality function would work in a completely identical way as it does not depend on the OS at all (the libc dependency in panic_unwind crate is just for the types) and only barely depends on the platform (it needs to know the register numbers that the landing pad uses and that's it).

@petrochenkov

This comment has been minimized.

Contributor

petrochenkov commented Jun 9, 2018

r? @nagisa

@rust-highfive rust-highfive assigned nagisa and unassigned petrochenkov Jun 9, 2018

@Havvy

This comment has been minimized.

Contributor

Havvy commented Jun 9, 2018

The documentation for this should be guide level in the nomicon and reference level in well, the reference.

@pietroalbini

This comment has been minimized.

Member

pietroalbini commented Jun 18, 2018

Ping from triage @nagisa! This PR needs your review.

@nagisa

This comment has been minimized.

Contributor

nagisa commented Jun 18, 2018

Is this really ready for stabilisation? The tracking issue still has references to a few issues that are, honestly, quite perplexing (for example why in the world #[no_mangle] is required).

Furthermore, I’m not entirely sure what are the steps before a stabilisation PR can be merged? I mildly recall having to go through a week of FCP? That would be for both T-libs (for approach, also initial issue is marked T-libs) and T-compiler (for implementation).

Lastly, if I remember well, documentation has to be ready at least in form of PRs for stabilisation? Comments indicate it is not quite ready yet.

@cramertj

This comment has been minimized.

Member

cramertj commented Jun 18, 2018

@nagisa Yes, before merging this PR a summary comment must be written on the tracking issue nominating the feature for FCP to stabilize and the stabilization must complete without new blocking objections.

@japaric japaric referenced this pull request Jun 20, 2018

Merged

stabilize #[used] #51363

@japaric

This comment has been minimized.

Member

japaric commented Jun 20, 2018

@steveklabnik

I'm imagining that the embedded docs your WG is working on may want to include it too?

We'll certainly be documenting #[panic_implementation] in the embedded book, which is geared towards people that want to learn how to do embedded Rust, as lots of people will have to deal with it. More obscure stuff, like #[used], (that most devs won't have to directly deal with) will go in the embedonomicon.

@whitequark

Unwinding works on no_std for me for a very long time, we use it in production. Is there anything specific you want to know?

Yes. Basically, does your unwinding implementation continue to work with #[panic_implementation]?

Less on-topic: could you point me to your unwinding implementation? I'd like to write documentation on how to get unwinding working on no_std. Right now it's unclear (in the docs I've seen) what eh_personality is for, how to compiler uses it and how it interacts with panic_fmt / panic_impl (if at all).

@nagisa

The tracking issue still has references to a few issues that are, honestly, quite perplexing (for example why in the world #[no_mangle] is required).

The #[no_mangle] issue that was reported looks like #51647 to me which, AFAICT, is the oom lang item undoing #49316 and not a #[panic_implementation] issue. Can't really tell as the issue is scarce on details, but I haven't required #[no_mangle] in any of my uses of #[panic_implementation] (I'm not using #[global_allocator] or the oom lang item though).

Lastly, if I remember well, documentation has to be ready at least in form of PRs for stabilisation?

I'll prep a PR for the reference and the nomicon.


So far it sounds like there are no concerns with the feature itself or its syntax. Can we start the FCPbot thing to have the appropriate team confirm that there are no concerns? cc @nikomatsakis

@nagisa

This comment has been minimized.

Contributor

nagisa commented Jun 20, 2018

@japaric

This comment has been minimized.

Member

japaric commented Jun 20, 2018

@pietroalbini

This comment has been minimized.

Member

pietroalbini commented Jun 25, 2018

Ping from triage @nagisa! You need to fcpbot this.

@steveklabnik

This comment has been minimized.

Member

steveklabnik commented Sep 7, 2018

kennytm added a commit to kennytm/rust that referenced this pull request Sep 7, 2018

Rollup merge of rust-lang#51366 - japaric:stable-panic-impl, r=Mark-S…
…imulacrum

stabilize #[panic_handler]

closes rust-lang#44489

### Update(2018-09-07)

This was proposed for stabilization in rust-lang#44489 (comment) and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in rust-lang#44489 (comment)

Documentation PRs:

- Reference. rust-lang-nursery/reference#362
- Nomicon. rust-lang-nursery/nomicon#75

---

`#[panic_implementation]` was implemented recently in rust-lang#50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. rust-lang#44489) but this PR is meant to start a discussion about those issues / questions with the language team.

(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in rust-lang#43054

Some unresolved questions from rust-lang#44489:

> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".

The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.

> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?

I believe @whitequark made more progress with unwinding in no-std since their last comment in rust-lang#44489. Perhaps they can give us an update?

---

Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp

@kennytm kennytm referenced this pull request Sep 7, 2018

Closed

Rollup of 9 pull requests #54036

bors added a commit that referenced this pull request Sep 7, 2018

Auto merge of #54036 - kennytm:rollup, r=kennytm
Rollup of 10 pull requests

Successful merges:

 - #51366 (stabilize #[panic_handler])
 - #53162 (rustdoc: collect trait impls as an early pass)
 - #53705 (#53576 Renaming TyAnon -> TyOpaque)
 - #53829 (Add rustc SHA to released DWARF debuginfo)
 - #53932 ([NLL] Remove base_place)
 - #53960 (Fix incorrect outer function type parameter message)
 - #53973 (Have rust-lldb look for the rust-enabled lldb)
 - #53987 (rustbuild: allow configuring llvm version suffix)
 - #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.)
 - #53999 (Stabilize 2018 edition)

Failed merges:

r? @ghost

bors added a commit that referenced this pull request Sep 7, 2018

Auto merge of #54036 - kennytm:rollup, r=kennytm
Rollup of 9 pull requests

Successful merges:

 - #51366 (stabilize #[panic_handler])
 - #53162 (rustdoc: collect trait impls as an early pass)
 - #53705 (#53576 Renaming TyAnon -> TyOpaque)
 - #53932 ([NLL] Remove base_place)
 - #53960 (Fix incorrect outer function type parameter message)
 - #53973 (Have rust-lldb look for the rust-enabled lldb)
 - #53987 (rustbuild: allow configuring llvm version suffix)
 - #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.)
 - #53999 (Stabilize 2018 edition)

Failed merges:

r? @ghost
@bors

This comment has been minimized.

Contributor

bors commented Sep 8, 2018

⌛️ Testing commit 358fc5b with merge 51bf99f...

bors added a commit that referenced this pull request Sep 8, 2018

Auto merge of #51366 - japaric:stable-panic-impl, r=Mark-Simulacrum
stabilize #[panic_handler]

closes #44489

### Update(2018-09-07)

This was proposed for stabilization in #44489 (comment) and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in #44489 (comment)

Documentation PRs:

- Reference. rust-lang-nursery/reference#362
- Nomicon. rust-lang-nursery/nomicon#75

---

`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.

(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054

Some unresolved questions from #44489:

> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".

The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.

> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?

I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?

---

Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
@bors

This comment has been minimized.

Contributor

bors commented Sep 8, 2018

💔 Test failed - status-travis

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Sep 8, 2018

The job dist-x86_64-apple of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:04:15]       Memory: 8 GB
[00:04:15]       Boot ROM Version: VMW71.00V.0.B64.1704110547
[00:04:15]       Apple ROM Info: [MS_VM_CERT/SHA1/27d66596a61c48dd3dc7216fd715126e33f59ae7]Welcome to the Virtual Machine
[00:04:15]       SMC Version (system): 2.8f0
[00:04:15]       Serial Number (system): VMlRZRy1z6uT
[00:04:15] 
[00:04:15] hw.ncpu: 4
[00:04:15] hw.byteorder: 1234
[00:04:15] hw.memsize: 8589934592
---
uploading "51bf99f99dc727866536b453b71006e9df903c2c/rustc-nightly-x86_64-apple-darwin.tar.xz" with {:content_type=>"application/x-xz", :acl=>"public-read"}
uploading "51bf99f99dc727866536b453b71006e9df903c2c/rustfmt-nightly-x86_64-apple-darwin.tar.gz" with {:content_type=>"application/gzip", :acl=>"public-read"}
uploading "51bf99f99dc727866536b453b71006e9df903c2c/rust-std-nightly-x86_64-apple-ios.tar.xz" with {:content_type=>"application/x-xz", :acl=>"public-read"}
uploading "51bf99f99dc727866536b453b71006e9df903c2c/rustc-nightly-x86_64-apple-darwin.tar.gz" with {:content_type=>"application/gzip", :acl=>"public-read"}
/Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call': Encountered a `SocketError` while attempting to connect to: (Aws::Errors::NoSuchEndpointError)
  https://rust-lang-ci2.s3.us-west-1.amazonaws.com/rustc-builds/51bf99f99dc727866536b453b71006e9df903c2c/rustfmt-nightly-x86_64-apple-darwin.tar.xz
This is typically the result of an invalid `:region` option or a
poorly formatted `:endpoint` option.
* Avoid configuring the `:endpoint` option directly. Endpoints are constructed
  from the `:region`. The `:endpoint` option is reserved for connecting to
  non-standard test endpoints.
* Not every service is available in every region.
* Never suffix region names with availability zones.
  Use "us-east-1", not "us-east-1a"
Known AWS regions include (not specific to this service):
ap-northeast-1
ap-northeast-2
ap-south-1
ap-southeast-1
ap-southeast-2
ca-central-1
eu-central-1
eu-west-1
eu-west-2
eu-west-3
sa-east-1
us-east-1
us-east-2
us-west-2
cn-north-1
cn-north-1
cn-northwest-1
us-gov-west-1
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/aws-sdk-core/plugins/s3_sse_cpk.rb:19:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/aws-sdk-core/plugins/s3_dualstack.rb:24:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/aws-sdk-core/plugins/s3_accelerate.rb:34:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/aws-sdk-core/plugins/idempotency_token.rb:18:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/aws-sdk-core/plugins/param_converter.rb:20:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/seahorse/client/plugins/response_target.rb:21:in `call'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/seahorse/client/request.rb:70:in `send_request'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-core-2.11.126/lib/seahorse/client/base.rb:207:in `block (2 levels) in define_operation_methods'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-resources-2.11.126/lib/aws-sdk-resources/services/s3/file_uploader.rb:42:in `block in put_object'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-resources-2.11.126/lib/aws-sdk-resources/services/s3/file_uploader.rb:49:in `open_file'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-resources-2.11.126/lib/aws-sdk-resources/services/s3/file_uploader.rb:41:in `put_object'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-resources-2.11.126/lib/aws-sdk-resources/services/s3/file_uploader.rb:34:in `upload'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/aws-sdk-resources-2.11.126/lib/aws-sdk-resources/services/s3/object.rb:252:in `upload_file'
 from /Users/travis/.rvm/gems/ruby-2.4.2/gems/dpl-s3-1.10.0/lib/dpl/provider/s3.rb:99:in `block (2 levels) in upload_multithreaded'
failed to deploy

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@kennytm

This comment has been minimized.

Member

kennytm commented Sep 8, 2018

@bors retry

Encountered a `SocketError` while attempting to connect to: (Aws::Errors::NoSuchEndpointError)

kennytm added a commit to kennytm/rust that referenced this pull request Sep 8, 2018

Rollup merge of rust-lang#51366 - japaric:stable-panic-impl, r=Mark-S…
…imulacrum

stabilize #[panic_handler]

closes rust-lang#44489

### Update(2018-09-07)

This was proposed for stabilization in rust-lang#44489 (comment) and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in rust-lang#44489 (comment)

Documentation PRs:

- Reference. rust-lang-nursery/reference#362
- Nomicon. rust-lang-nursery/nomicon#75

---

`#[panic_implementation]` was implemented recently in rust-lang#50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. rust-lang#44489) but this PR is meant to start a discussion about those issues / questions with the language team.

(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in rust-lang#43054

Some unresolved questions from rust-lang#44489:

> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".

The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.

> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?

I believe @whitequark made more progress with unwinding in no-std since their last comment in rust-lang#44489. Perhaps they can give us an update?

---

Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp

bors added a commit that referenced this pull request Sep 8, 2018

Auto merge of #54051 - kennytm:rollup, r=kennytm
Rollup of 11 pull requests

Successful merges:

 - #51366 (stabilize #[panic_handler])
 - #53162 (rustdoc: collect trait impls as an early pass)
 - #53932 ([NLL] Remove base_place)
 - #53942 (Rewrite `precompute_borrows_out_of_scope` for fewer hash table lookups.)
 - #53973 (Have rust-lldb look for the rust-enabled lldb)
 - #53981 (Implement initializer() for FileDesc)
 - #53987 (rustbuild: allow configuring llvm version suffix)
 - #53993 (rustc_resolve: don't record uniform_paths canaries as reexports.)
 - #54007 (crates that provide a `panic_handler` are exempt from the `unused_extern_crates` lint)
 - #54040 (update books for next release)
 - #54050 (Update `petgraph` dependency to 0.4.13 to fix build with nightly)

Failed merges:

r? @ghost
@bors

This comment has been minimized.

Contributor

bors commented Sep 8, 2018

⌛️ Testing commit 358fc5b with merge ff59ab1...

bors added a commit that referenced this pull request Sep 8, 2018

Auto merge of #51366 - japaric:stable-panic-impl, r=Mark-Simulacrum
stabilize #[panic_handler]

closes #44489

### Update(2018-09-07)

This was proposed for stabilization in #44489 (comment) and its FCP with disposition to merge / accept is nearly over. The summary of what's being stabilized can be found in #44489 (comment)

Documentation PRs:

- Reference. rust-lang-nursery/reference#362
- Nomicon. rust-lang-nursery/nomicon#75

---

`#[panic_implementation]` was implemented recently in #50338. `#[panic_implementation]` is basically the old `panic_fmt` language item but in a less error prone (\*) shape. There are still some issues and questions to sort out around this feature (cf. #44489) but this PR is meant to start a discussion about those issues / questions with the language team.

(\*) `panic_fmt` was not type checked; changes in its function signature caused serious, silent binary size regressions like the one observed in #43054

Some unresolved questions from #44489:

> Should the Display of PanicInfo format the panic information as "panicked at 'reason',
> src/main.rs:27:4", as "'reason', src/main.rs:27:4", or simply as "reason".

The current implementation formats `PanicInfo` as the first alternative, which is how panic messages are formatted by the `std` panic handler. The `Display` implementation is more than a convenience: `PanicInfo.message` is unstable so it's not possible to replicate the `Display` implementation on stable.

> Is this design compatible, or can it be extended to work, with unwinding implementations for
> no-std environments?

I believe @whitequark made more progress with unwinding in no-std since their last comment in #44489. Perhaps they can give us an update?

---

Another unresolved question is where this feature should be documented. The feature currently doesn't have any documentation.

cc @rust-lang/lang
cc @jackpot51 @alevy @phil-opp
@bors

This comment has been minimized.

Contributor

bors commented Sep 8, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: Mark-Simulacrum
Pushing ff59ab1 to master...

@bors bors merged commit 358fc5b into rust-lang:master Sep 8, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@japaric japaric deleted the japaric:stable-panic-impl branch Sep 8, 2018

josephlr added a commit to josephlr/bootloader that referenced this pull request Sep 11, 2018

Remove stabilized features
panic_implemenation was renamed to panic_handler:
   rust-lang/rust#44489 (comment)
panic_handler was stablized:
   rust-lang/rust#51366

`cargo check` now succeeds without warnings

@josephlr josephlr referenced this pull request Sep 11, 2018

Merged

Remove stabilized features #25

phil-opp added a commit to rust-osdev/bootloader that referenced this pull request Sep 30, 2018

Remove stabilized features (#25)
panic_implemenation was renamed to panic_handler:
   rust-lang/rust#44489 (comment)
panic_handler was stablized:
   rust-lang/rust#51366

`cargo check` now succeeds without warnings
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment