This is a 🙋 feature

Description

GUI applications cant display the message on the terminal so I have added a native message box so they can use human-panic. The x11 implementation is based on the SDL ShowSimpleMessageBox source code: https://github.com/spurious/SDL-mirror/blob/master/src/video/x11/SDL_x11messagebox.c Non-ascii characters aren't working on the linux implementation, no idea whats up with that. Mac OS is left unimplemented as I don't have access to such a machine. Enabled by the gui feature

Scope

This may not fit it into the scope of this project, due to:

• Extending the scope to GUI applications.
• Lots of unsafe code which is especially undesirable in a panic handler.

This feature is something I need, so if this change doesn't fit into this project I will need to maintain a fork.

Checklist

• [x] tests pass
• [x] documentation is changed or added

Semver Changes

Major change

Screenshots

Linux (i3 wm)

Windows

This pull request attempts to unify the currently ongoing efforts to refactor and clean up this crate. I went a step further with it.

This PR combines #1 and #4 functionality and cleanliness-wise but also changes the core feature of the crate. Now, instead of having to wrap panics in human_panic::catch_unwind, the functionality is now boiled down to a single macro that the user has to invoke at the beginning of the crate.

#[macro_use]
extern crate human_panic;

fn main() {
  setup_panic!();

  // ...

  panic!("OMG EVERYTHING IS ON FIRE!!!");
}

I hope I didn't fuck anything up during the merging. Looking back, I should have merged #4 into #1 first, then merge that into my stuff :smirk:

Comments? @killercup @yoshuawuyts

🐛 Set cause, whether we're on nightly or not.

Previously there were two cases with two sub-cases:

• if compiled with nightly:
  • if there is a panic message: set it as cause
  • if there is no panic message: set cause to "Unknown"
• if not compiled with nightly: set cause to "Error cause could not be determined by the application.", and also:
  • if there is a panic message: attach it straight to the expl string as "Cause: ."

That seems oddly complicated. This PR changes that to:

• if there is a panic message (no matter if we're on nightly or not): set it as cause
• if there is no panic message (no matter if we're on nightly or not): set cause to "Unknown"

Checklist

• [x] tests pass
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added

Context

Vaguely related to https://github.com/rust-cli/human-panic/issues/55.

Semver Changes

This changes the format of the message users see. I think it's a bugfix, but if changing what users see is considered a breaking change, then this is a breaking change.

This is a pretty general refactoring of the code.

The goal of this PR is to make this a crate that is useful in more general contexts. For this, I've:

• put the nightly-only external_doc feature behind a feature flag
• changed how clippy is used on CI by installing cargo-clippy in a new travis builder
• removed failure and unindent as dependencies
• replaced console with termcolor which is known to work on Windows

For more information, see the individual commit messages.

Semver Changes

This does not change observable behavior.

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! :)

Update the project to 2018 edition in both code and documentation for usage, prunes unused dependencies and removes dependency on failure, preferring the std Error trait.

There was also a misleading error message about not being able to find a temporary file directory, which would have actually have been caused by a failure to encode a filepath into UTF-8 (https://doc.rust-lang.org/src/std/path.rs.html#1848-1850). However this error should not happen anyway by just using the PathBuf directly to make the full path for the persisted file output.

Should resolve https://github.com/rust-cli/human-panic/issues/57

Choose one: is this a 🐛 bug fix, a 🙋 feature, or a 🔦 documentation change? Feature and docs

Checklist

• [x] tests pass
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added

Context

https://github.com/rust-cli/human-panic/issues/57

Semver Changes

Should take a minor bump potentially, but no changes to APIs.

Choose one: 🙋 feature

Checklist

• [X] tests pass

Context

Hi! 👋 I was wondering if you'd be opposed to the idea of exposing the report mod as public. It is pretty useful on its own and I intend to use the Report struct directly instead of printing the result.

No worries if you don't want to increase the API surface, though. :)

Semver Changes

It changes the public interface, but in a backwards-compatible way. So minor bump should be fine.

Cargo guidelines are to not set a homepage if it isn't any different than the repository URL. This causes the report to not have any link back to file an issue. If the repository is available, print it as well.

Note that I've tried to find a reference to the "don't set homepage if it isn't the same" guideline, but haven't found it yet.

The environment variable is not available yet. See https://github.com/rust-lang/cargo/pull/6096

Choose one: is this a 🙋 feature?

Checklist

• [x] tests pass
• [x] documentation is changed or added

Context

None

Semver Changes

Major; the Metadata structure has a new field that isn't specified in existing code.

Choose one: This a 🐛 bug fix

Including original panic-cause in report

Okay so this PR is a bit of a dilemma. The API we need to get the original panic message isn't stable and requires a feature flag. We can conditionally enable the feature flag for nightly users but that doesn't quite deal with the problem of what to do when someone is using human-panic on stable.

As far as I can see there's no other API to get that information? We could always just gate it all away behind the nightly feature and just ommit a static "not supported" or something when running on stable.

The tests pass (provided you pass --features nightly for now). Wanted to open this PR to discuss how to proceed :)

• [x] tests pass
• [x] tests and/or benchmarks are included
• [ ] documentation is changed or added

This fixes #40

This should be a minor bump I believe?

The Report struct isn't exported so adding a field there isn't gonna make a difference 🤷

Choose one: is this a 🐛 bug fix

Metadata<'a> is wrong, since only a==static will compile. This changes it for clarity.

Checklist

• [ ] tests pass (still no tests)
• [ ] tests and/or benchmarks are included
• [ ] documentation is changed or added

Context

N/A

Semver Changes

Changed Metadata is technically pub, though users of this library are unlikely to provide their own.

Wow, there's a lot of stuff going on in this repo! This is a rollup of #6 and #9 -- and I'm pretty sure also of #8 of which #9 is pretty much a superset.

So, to summarize:

• This fixes the tests
• This makes clippy and rustfmt happy
• This uses Path/PathBuf instead of String in a few places

…and it finally it bumps the version to 0.3 because, even though print_msg now accepts strictly more inputs (you can still pass in a String but now also give it a Path or PathBuf of &str), the output type of handle_dump changed :(

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

Detected Package Files

• Cargo.toml (cargo)

Configuration Summary

Based on the default config's presets, Renovate will:

• Start dependency updates only once this onboarding PR is merged
• Enable Renovate Dependency Dashboard creation.
• If Renovate detects semantic commits, it will use semantic commit type fix for dependencies and chore for all others.
• Ignore node_modules, bower_components, vendor and various test/tests directories.
• Autodetect whether to pin dependencies or maintain ranges.
• Rate limit PR creation to a maximum of two per hour.
• Limit to maximum 10 open PRs at any time.
• Group known monorepo packages together.
• Use curated list of recommended non-monorepo package groupings.
• A collection of workarounds for known problems with packages.

🔡 Would you like to change the way Renovate is upgrading your dependencies? Simply edit the renovate.json in this branch with your custom config and the list of Pull Requests in the "What to Expect" section below will be updated the next time Renovate runs.

What to Expect

With your current configuration, Renovate will create 9 Pull Requests:

🚸 Branch creation will be limited to maximum 2 per hour, so it doesn't swamp any CI resources or spam the project. See docs for prhourlylimit for details.

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.

This PR has been generated by Mend Renovate. View repository job log here.

This is a 🙋 feature.

Checklist

• [x] tests pass
• [ ] tests and/or benchmarks are included - is this necessary/possible for this?
• [x] documentation is changed or added

Context

Fixes #31

Semver Changes

Major release - it changes the Report struct. I don't think 2.0 is released yet, so that would fit perfectly!

I have very little experience contributing to Rust crates, so if I made any mistakes, let me know!

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 ffe447a2c66b41b338edb440470c42050bbc0dd5 using Rust 1.36.0 on Linux.

Choose one: this is a 🙋 feature

This resolves #77 by adding a repository field to the Metadata struct and a corresponding "Repository: ..." line to the message that gets printed

Checklist

• [x] tests pass
• [x] tests and/or benchmarks are included
• [x] documentation is changed or added

Context

See #77.

Semver Changes

This is a breaking change because it adds a field to Metadata, which doesn't have the #[non_exhaustive] attribute.

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

| Software | Version(s) | | ---------------- | ---------- | | Package | | Runtime | | Package Manager | | Operating System |