stabilize #[panic_handler] #51366

japaric · 2018-06-05T09:30:18Z

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. document #[panic_handler] reference#362
Nomicon. document #[panic_handler] 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

rust-highfive · 2018-06-05T09:30:22Z

r? @petrochenkov

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

rust-highfive · 2018-06-05T10:31:41Z

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 · 2018-06-05T12:29:40Z

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 · 2018-06-05T13:00:39Z

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

alevy · 2018-06-05T14:09:34Z

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 · 2018-06-05T16:19:08Z

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 · 2018-06-05T16:42:05Z

It isn’t. The book’s objective is to teach you Rust; you don’t need to know any of this to learn how to program in Rust. It *is* worth documenting, but in our current set of resources, the reference and/or nomicon is the right place. As we develop more books for the shelf, it might fit in there too.

…

On Jun 5, 2018, at 4:09 PM, Amit Levy ***@***.***> wrote: 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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

whitequark · 2018-06-05T23:34:34Z

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 · 2018-06-09T15:53:00Z

r? @nagisa

Havvy · 2018-06-09T21:19:47Z

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

pietroalbini · 2018-06-18T09:21:50Z

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

nagisa · 2018-06-18T11:48:51Z

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 · 2018-06-18T18:32:07Z

@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 · 2018-06-20T02:11:21Z

@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 · 2018-06-20T04:54:19Z

I'll fcpbot this evening.

…

On Wed, Jun 20, 2018, 05:12 Jorge Aparicio ***@***.***> wrote: @steveklabnik <https://github.com/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 <https://github.com/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 <https://github.com/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 <#51647> to me which, AFAICT, is the oom lang item undoing #49316 <#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 <https://github.com/nikomatsakis> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51366 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0uLg6HIZN-vxDx2ERUTmMK_33CSAks5t-a-JgaJpZM4Uad8d> .

japaric · 2018-06-20T19:20:02Z

Documentation PRs: rust-lang/reference#362 and rust-lang/nomicon#75

pietroalbini · 2018-06-25T08:52:22Z

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

bors · 2018-09-08T01:25:35Z

⌛ Testing commit 358fc5b with merge 51bf99f99dc727866536b453b71006e9df903c2c...

bors · 2018-09-08T04:14:49Z

💔 Test failed - status-travis

rust-highfive · 2018-09-08T04:14:50Z

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 · 2018-09-08T07:50:58Z

@bors retry

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

@whitequark

…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/reference#362 - Nomicon. rust-lang/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

@ghost

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 · 2018-09-08T09:23:54Z

⌛ Testing commit 358fc5b with merge ff59ab1...

@whitequark

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/reference#362 - Nomicon. rust-lang/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 · 2018-09-08T11:53:11Z

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

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

1950: remove all uses of lang_items unstable feature r=ppannuto a=hudson-ayers ### Pull Request Overview This pull request removes all uses of the lang_items unstable feature, to get us closer to building Tock on stable rust. Originally, lang_items was required to declare the global panic handler, but that was changed by rust-lang/rust#51366 . After that, we seem to have just kept it around for declaring a dummy `eh_personality()` implementation, which I understand is not needed if you build with panic=abort (which we do for both release and debug builds). see: https://os.phil-opp.com/freestanding-rust-binary/ ### Testing Strategy This pull request was tested by compiling, running a normal app on Imix, and by panicing intentionally and observing the output looks normal. ### TODO or Help Wanted Confirmation that I am correct in my understanding that we do not need eh_personality because we always use panic=abort. ### Documentation Updated - [x] No updates are required. ### Formatting - [x] Ran `make prepush`. Co-authored-by: Hudson Ayers <hayers@stanford.edu>

rust-highfive assigned petrochenkov Jun 5, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 5, 2018

4e554c4c mentioned this pull request Jun 7, 2018

Add backtracing in panic ESALP/ESALP-1#41

Open

pietroalbini added the relnotes Marks issues that should be documented in the release notes of the next release. label Jun 7, 2018

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

pietroalbini added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 18, 2018

japaric mentioned this pull request Jun 20, 2018

stabilize #[used] #51363

Merged

This was referenced Jun 20, 2018

document #[panic_handler] rust-lang/reference#362

Merged

document #[panic_handler] rust-lang/nomicon#75

Merged

pietroalbini added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 25, 2018

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 8, 2018

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 8, 2018

kennytm mentioned this pull request Sep 8, 2018

Rollup of 10 pull requests #54051

Merged

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

This was referenced Sep 8, 2018

stabilize outlives requirements #53793

Merged

Report const eval error inside the query #53821

Merged

japaric deleted the stable-panic-impl branch September 8, 2018 12:04

josephlr mentioned this pull request Sep 11, 2018

Remove stabilized features rust-osdev/bootloader#25

Merged

phil-opp mentioned this pull request Oct 7, 2018

rust_begin_unwind required for panic=abort #38281

Closed

SimonSapin mentioned this pull request Nov 25, 2019

Tracking issue for PanicInfo::message #66745

Closed

9 tasks

hudson-ayers mentioned this pull request Jun 17, 2020

remove all uses of lang_items unstable feature tock/tock#1950

Merged

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

stabilize #[panic_handler] #51366

stabilize #[panic_handler] #51366

japaric commented Jun 5, 2018 •

edited

Loading

rust-highfive commented Jun 5, 2018

rust-highfive commented Jun 5, 2018

steveklabnik commented Jun 5, 2018

bors commented Jun 5, 2018

alevy commented Jun 5, 2018

nikomatsakis commented Jun 5, 2018 •

edited

Loading

steveklabnik commented Jun 5, 2018 via email

whitequark commented Jun 5, 2018

petrochenkov commented Jun 9, 2018

Havvy commented Jun 9, 2018

pietroalbini commented Jun 18, 2018

nagisa commented Jun 18, 2018

cramertj commented Jun 18, 2018

japaric commented Jun 20, 2018

nagisa commented Jun 20, 2018 via email

japaric commented Jun 20, 2018

pietroalbini commented Jun 25, 2018

bors commented Sep 8, 2018

bors commented Sep 8, 2018

rust-highfive commented Sep 8, 2018

kennytm commented Sep 8, 2018

bors commented Sep 8, 2018

bors commented Sep 8, 2018

stabilize #[panic_handler] #51366

stabilize #[panic_handler] #51366

Conversation

japaric commented Jun 5, 2018 • edited Loading

Update(2018-09-07)

rust-highfive commented Jun 5, 2018

rust-highfive commented Jun 5, 2018

steveklabnik commented Jun 5, 2018

bors commented Jun 5, 2018

alevy commented Jun 5, 2018

nikomatsakis commented Jun 5, 2018 • edited Loading

steveklabnik commented Jun 5, 2018 via email

whitequark commented Jun 5, 2018

petrochenkov commented Jun 9, 2018

Havvy commented Jun 9, 2018

pietroalbini commented Jun 18, 2018

nagisa commented Jun 18, 2018

cramertj commented Jun 18, 2018

japaric commented Jun 20, 2018

nagisa commented Jun 20, 2018 via email

japaric commented Jun 20, 2018

pietroalbini commented Jun 25, 2018

bors commented Sep 8, 2018

bors commented Sep 8, 2018

rust-highfive commented Sep 8, 2018

kennytm commented Sep 8, 2018

bors commented Sep 8, 2018

bors commented Sep 8, 2018

japaric commented Jun 5, 2018 •

edited

Loading

nikomatsakis commented Jun 5, 2018 •

edited

Loading