Choose one: 🐛 bug report

Since the release of v1.0.2 yesterday (#65), wasm-pack no longer installs. It's because of #45, which added a field to the Metadata struct.

$ cargo install wasm-pack
...
   Compiling wasm-pack v0.9.1
error[E0063]: missing field `repository` in initializer of `human_panic::Metadata`
   --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/wasm-pack-0.9.1/src/main.rs:105:16
    |
105 |     let meta = human_panic::Metadata {
    |                ^^^^^^^^^^^^^^^^^^^^^ missing `repository`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0063`.
error: failed to compile `wasm-pack v0.9.1`, intermediate artifacts can be found at `/tmp/cargo-install8pgGsr`

Caused by:
  could not compile `wasm-pack`.

To learn more, run the command again with --verbose.

rustwasm/wasm-pack#818 is the corresponding wasm-pack issue.

#45 is an incompatible change and really should have occasioned a major version increment.

Your Environment

$ cargo --version
cargo 1.42.0 (86334295e 2020-01-31)

Currently the setup_panic! macro sets itself up unconditionally. I think a good default would be to ignore itself if RUST_BACKTRACE is setup up explicitly - that way it's not intended for normal humans, but for an environment that already expects the standard rust backtraces, or for developers who explicitly want to turn this on.

This also makes it immensely useful by default during debugging, and development, as there's no need to wrap the setup_panic around a condition. I like the one setup, and would like to avoid putting an ugly wrapper around it. Clearly, this is not something intended during the development process.

Hopefully, most people feel the same, and this can be the default behavior! :)

This is a work-in-progress tracking issue for a 2.0 release of human-panic, set in motion because of #45

New Features

• Show message only to humans (#48 | PR: #50)
• Include original panic messages (#40 | PR: #43)
• Include rustc version program was compiled with (#31)
• Provide a way for tools to hook into panic reports (#30)
• Provide a way for crash reporters to be called (#7)
• Split website and repository fields ( - | PR: #45)
• Update to Rust 2018 (#57)

Could this crate at a later date optionally allow for sending the report on behalf of the user if they allow it rather than manual submission from the user? Or would that be the responsibility of another crate that builds off this one?

The code attempts to downcast to &str but this will return None if the PanicInfo.payload() is a String. For example, consider the following panic:

panic!("this is a {}", "test");

The "Cause" will not be displayed in the "explanation" portion of the dump file as this panic has a payload of type String which is not &str. How do I get the Cause to show when I use a panic such as this? Or does this require a code change to support downcasting to other types such as String?

So...there seems to be a problem with reading the metdata for the error message.

let _version = env!("CARGO_PKG_VERSION");
let name = env!("CARGO_PKG_NAME");
let authors = env!("CARGO_PKG_AUTHORS");
let homepage = env!("CARGO_PKG_HOMEPAGE");

When using human-panic, in my CLI it still includes the information to your crate:

spacekookie@azedes ~/P/poke> target/debug/poke
Well, this is embarrasing.

human-panic had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "<reports not generated yet>". Submit an issue or email with the subject of "human-panic Crash Report" and include the report as an attachment.

- Homepage: https://github.com/yoshuawuyts/human-panic
- Authors: Yoshua Wuyts <[email protected]>

We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!

I assume I'm using the crate correctly? This is my main:

fn main() {
    human_panic::catch_unwind(|| {
        panic!("something went wrong");
    });
}

In general it's not obvious how to use this? Because the panic text I provide is for example completely ignored. And isn't there a way to generically catch panic! calls?

Edit: Looking at the code, it looks like #1 will fix this? 😅 I didn't check there was a PR before opening the issue

Choose one: this is a 🐛 bug report

A number of this crate's dependencies no longer compile on Rust 1.36.0, meaning this crate is no longer usable on Rust 1.36.0.

Expected Behavior

Running cargo +1.36.0 build should pass.

Current Behavior

There are almost certainly more compile errors, but running cargo +1.36.0 build shows that rustc-demangle and memchr no longer work with Rust 1.36.0.

Possible Solution

There are two possible solutions:

1. Update this crate's MSRV (a breaking change)
2. Pin the offending crates to a supported version

I don't believe the second solution is feasible because the offending crates are transitive dependencies.

The best solution would be to bump the MSRV and create a new major release. While we're at it, we could use some newer Rust features so there are less breaking changes in the future or take advantage of recent features.

• Add the #[non_exhaustive] attribute to Metadata so adding extra metadata to a report isn't a breaking change
  • This would require introducing a builder API so people can initialize Metadata themselves

Context

I don't particularly mind because I almost always use nightly or stable Rust, but MSRV is very important to some people and we should try to accommodate them.

Code Sample

$ git checkout ffe447a2c66b41b338edb440470c42050bbc0dd5
$ cargo +1.36.0 test
  ...
error: cannot find macro `matches!` in this scope
   --> /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-demangle-0.1.21/src/v0.rs:700:20
    |
700 |                 if matches!((quote, c), ('\'', '"') | ('"', '\'')) {
    |                    ^^^^^^^

error: aborting due to previous error

error: Could not compile `rustc-demangle`.
warning: build failed, waiting for other jobs to finish...
error[E0658]: naming constants with `_` is unstable
  --> /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/memchr-2.4.1/src/memmem/prefilter/fallback.rs:37:1
   |
37 | const _: PrefilterFnTy = find;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: for more information, see https://github.com/rust-lang/rust/issues/54912

error[E0658]: naming constants with `_` is unstable
 --> /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/memchr-2.4.1/src/memmem/prefilter/x86/sse.rs:9:1
  |
9 | const _: PrefilterFnTy = find;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: for more information, see https://github.com/rust-lang/rust/issues/54912

error[E0658]: non exhaustive is an experimental feature
   --> /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/memchr-2.4.1/src/memmem/prefilter/mod.rs:152:1
    |
152 | #[non_exhaustive]
    | ^^^^^^^^^^^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/44109

error: aborting due to 3 previous errors

Your Environment

This was tested against ffe447a using Rust 1.36.0 on Linux.

It is currently only used in report.rs to serialize a few strings to a file. The whole toml dependency is an overkill for this, just an additional dependency to be upgraded all the time.

String escaping could be reimplemented locally if you want to generate a valid TOML and not break compatibility, just escape the quotes and backslashes or something like this.

Is it automatically enabled?

I expect README to have more about it.

If possible, please add the following sentence to the human-panic.

It only displays a human-friendly panic message in release mode:

$ cargo run --release

Thank you.

This is a 🐛 bug report.

Expected Behavior

The changelog should contain entries for all released versions.

Current Behavior

As of tag v1.0.3, the changelog only mentions the 0.3.0 release from 2018, and is missing entries for releases 1.0.1 and 1.0.3.

Possible Solution

Document what changed from 0.3.0 to 1.0.1 and from 1.0.1 to 1.0.3.

Context

I am working on a CLI application using human-panic and I'm unsure whether I should update the human-panic dependency. I was looking for the relevant changelog entries to figure out whether I should update, and couldn't find the relevant information.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

🐛 bug report

I noticed .travis.yml isn't running tests on the oldest supported version of rust. This makes it harder for users to find what version of rust is supported and makes it easy to accidentally change the oldest supported version without fanfare.

This came up when someone reported to me that they had to upgrade their version of rust to try out human-panic due to a use-statement syntax being used.

See docmatic for an example on how to enforce this.

https://docs.rs/human-panic/1.0.0/human_panic/ =>
The requested resource does not exist

Choose one: 🙋 feature request

Something I noticed in sentry, which is an enterprise-y form of human-panic, is the ability to capture logged warnings / errors. This could be a useful feature for human-panic as well to get extra context for why things might have failed.

See their log integration for their API and what features it provides.

As per #15, we should probably setup some tests. @killercup made a good suggestion that we could use https://github.com/assert-rs/assert_cli for that.

Looking at the way human-panic handles backtrace, I feel like it would be better to suggest to stop printing unnecessary frames we get from backtrace as it has own calls, and instead jump straight to user code. This is how I made for my lazy panic handlers when backtrace is on https://github.com/DoumanAsh/lazy-panic.rs/blob/master/src/formatter.rs#L189-L202

Expected Behavior

Prints stacktrace from user code

Current Behavior

Prints stacktrace from human-panic and its dependency backtrace

Possible Solution

Calculate where user code's panic starts and start printing from this point (Not sure if it is platform dependent number, but both windows and linux had the same stack trace in my experiments)

Context

I just feel it would improve usability for reports with backtrace

Hello,
I think adding a more complex example where we define our human panic message with perhaps multiple one, could be very interesting to have.
thanks for the package

In the callback given to set_hook, we have an explicit unwrap/expect:

https://github.com/yoshuawuyts/human-panic/blob/d86232967d3bf9dc868a4cd68bab2e1004b6d2dc/src/lib.rs#L47-L48

This can lead to panicking while handling a panic. I'm not entirely sure what happens then (we should probably test it), but we can easily mitigate this by just printing a generic error instead.

One step further would be to handle explicit error cases, e.g., not being able to write the temporary file and printing the report to stdout instead.

🔦 question?

Expected Behavior

When using panic!, the log message is displayed prior to the stack trace. As an example, this statement

panic!("feed item {:?} can't be parsed, as it doesn't have pub_date", &self);

will display an error message in stdout prior to the stack trace.

Current Behavior

The generated log file contains lots of info, but not this log message

Possible Solution

How could I add the log message to that file ?

Context

I'm using human_panic in a command-line app I'm developing

Code Sample

Your Environment

name = 'rrss2imap'
operating_system = 'windows'
crate_version = '0.1.3-alpha.0'

(I'm quite sure this section could be automatically generated when using human_panic)

🐛 bug report

Expected Behavior

When I look at the generated log file, I expect to see the name of my own crate, the current version, and some information.

Current Behavior

I see a panic as if I'm inside the human-panic crate.

name = "human-panic"
operating_system = "unix:OSX"
crate_version = "0.2.0"
explanation = "Cause: Oh snap. Panic occurred in file 'src/main.rs' at line 69\n"
method = "Panic"

Possible Solution

No idea.

Context

I'm trying to set it up in a small CLI app.

Code Sample

Unfortunately, it's in proprietary code so I cannot link to it, but this is what I've got:

 fn main() {
  setup_panic!();
  panic!("Oh snap");

I'm literally just testing it out, it's working, but the outputted log file isn't what I expected.

Your Environment

For human-panic 2.0 we definitely want to upgrade the codebase to Rust 2018. This should be done before making any structural changes to how the library works and is potentially a low-hanging fruit for someone to contribute to.

I'm trying to create my own panic hook using the reporting mechanism from this crate but with my own error message. Something like this:

https://github.com/themaxdavitt/human-panic-metadata-poc/blob/c1ce95c11449018aa4f3bde9868a34d54798d110/wrapper/src/lib.rs#L24-L33

However, currently the metadata! macro refers to the Metadata struct without using $crate to help the compiler know where that Metadata type is defined, leading to the following error:

error[E0422]: cannot find struct, variant or union type `Metadata` in this scope
 --> user/src/bin/broken.rs:4:5
  |
4 |     wrapper::broken_custom_panic_hook!();
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in this scope
  |

If I replace the metadata! invocation with the contents of the macro itself (using $crate to refer to the Metadata type to populate), it compiles as expected:

https://github.com/themaxdavitt/human-panic-metadata-poc/blob/c1ce95c11449018aa4f3bde9868a34d54798d110/wrapper/src/lib.rs#L7-L21

Here's the repo I created demonstrating this. Let me know if you have any questions and thanks for maintaining this crate!

EDIT: I know this is pretty minor, and can easily be fixed by just useing the type before invoking the macro, I just wanted to leave an issue about it in case someone else stumbles across this.

Choose one: is this a 🙋 feature request

Expected Behavior

When the Cargo.toml parameter repository is present and homepage is absent, no URL is included in the message. If one wants to add the github URL, they need to set it in homepage. It's a bad practice since homepage is for a real home page, not a repository.

Current Behavior

repository is ignored.

Possible Solution

It would be nice to have a fallback to repository if homepage is absent. Or better, print both since they add different useful information.

Context

Code Sample

Your Environment

Choose one: is this a 🐛 bug report

Missing docs are a bug, right? 😆

So what I am missing is just a short explanation where to call the setup_panic!() macro, actually: Inside main? Outside of any function?
Just a bit of confusion on my end because the docs do not show where to put the call.

Thanks for this nice crate!

It would be nice to be able to specify a custom error printer, for cases where stderr is not used. For example, with a graphical application, one could use https://lib.rs/crates/msgbox.

It would be great if we could have a new release for the changes made in #63

cc @johnchildren

Expected Behavior

I was investigating human-panic for possible usage in Clippy because we usually get a lot of failures due to being on nightly and depending on a lot of internal APIs.

Is there a possibility to include the current rustc version in the report?
Ideally, that would include everything that's shown in rustc -vV.

Current Behavior

It's currently not included.

Possible Solution

I think executing rustc -vV, capturing the output and adding it to the report file should work, but not sure.
I'd be happy to work on this if you have nothing against including that in the report.

Expected Behavior

Without human-panic, my program says

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21

I'd expect the report file to contain this information, as well.

Current Behavior

The "unwrap on a Non value" information is gone. The report only says

explanation = '''
Panic occurred in file 'libcore/option.rs' at line 335
'''
method = 'Panic'

Your Environment

I'm using human-panic 1.0.0.

The panic information is now saving in a temp file. However, if the machine reboot, the file will be lost, and also, we want to use the regular path, so that we can easy to find the panic file.

Would it be possible to set a custom error message?

Perhaps a project could have a text file or config file that it passes as a string to human-panic's sourcing of its text.

This would also fix #7 (comment).

human-panic currently skips a hardcoded number of frames which is... not what you want to do:

Rust emits two magic frame names to delimit the "runtime glue" from the "real stack". Unfortunately the backtrace crate doesn't support handling that for you. As such I made backtrace-ext::short_frames_strict to do that for everyone who is implementing this kind of logic.

The example is basically already human-panic's impl because I found this problem in miette which copied your impl. I can do the PR for you but I wasn't sure if you were ok with adding this dep (it's basically one complicated function but slightly factored out so I could unit test the crap out of it because you should never trust backtraces to provide decent input).

(NB: at the time of filing this issue I've published 0.2.0 but docs.rs is super backlogged. 0.2.0 includes fixes from me adding all the comprehensive tests, and also removes the "re-export of all of Backtrace" because I realized it's goody. If you see this issue soon enough just know that this line in the example changed to import Backtrace from backtrace and not backtrace-ext.)
(0.2.0 is live now, also I cut 0.2.1 to lower the msrv)

Feature request

Context

Hey guys. I'm currently develop an idea for a crate which possibly fit in you environment.
As I'm less experienced rust developer, it often happens to me that i search certain Error messages which i don't understand or kind of errors where i need some examples to understand the true purpose of the function. So my idea is to write a crate to search after the error und list possible solutions by showing the links. It doesn't need necessarily a link to stackoverflow, instead it can be modular and e.g. search on rust docs and so on.

What do you think?

🙋 feature request

Expected Behavior

When my program panics, I want the user to see a [email protected] email and a https://example.com/support link.

Current Behavior

When my program panics, the user sees a [email protected] email and a https://internal.example.com/source-control-system/project-name link because these are what is set in the Cargo.toml.

Possible Solution

It'd be nice to have two macros:

1. takes no arguments and uses the values from Cargo.
2. takes one argument, a Metadata struct, and uses that data in the outputted text.

I realize, though, that this getting closer to "custom message text" which could be great if it could be templated in some way.

Examples:

set_panic!()

set_panic!(Metadata{ authors: "[email protected]", homepage: "https://example.com/support" })

Context

This affects me because I'm developing a commercial product in which I'd like to use human-panic and I don't want my developers' individual email addresses to be exposed to the user nor do I want to change the Cargo.toml authors because we're currently using that to track who's knowledgeable of that codebase at the moment.

While on desktop applications it makes sense to store the crash report in a file, on mobile devices it can be challenging to actually find the report file, especially for end users. So for these cases I would like to print the whole report, after message, such that it is easier to report. Is this sth you would consider? Alternatively having a hook to customize the file writing would likely solve this issue as well. Thank you

Right now errors look like this:

name = "human-panic"
operating_system = "unix:Unknown"
crate_version = "0.1.0"
explanation = "Cause: Ooops\n\nBacktrace: \n\n"
method = "Err"

How can we do better in terms of formatting? Bonus points if you include a Serializable struct example too!

1.0.0 permanently changes the console color to red if there's a panic. This is fixed in #37, but hasn't been released to crates.io. It's a nice fix, could we release it?