Skip to content

Conversation

@spacekookie
Copy link
Collaborator

@spacekookie spacekookie commented Sep 20, 2018

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

  • tests pass
  • 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 🤷

@spacekookie spacekookie changed the title **Choose one:** This a 🐛 bug fix Including original panic-cause in report Sep 20, 2018

* Carrying over metadata from first macro call to properly
include metadata in crash dumps.
* Making Method derive Copy (Katharina)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops oops, it looks like this file was written using an old version of changelog. There was a bug that created these ^M instances which has since been fixed. Could you perhaps try updating and running this again?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a changelog installed? How is this tool invoked?

src/lib.rs Outdated
//!
//! When an error eventually occurs, you probably will want to know about it. So
//! When an error eventually occurs, you proba
//! #[cfg(feature = "nightly")]bly will want to know about it. So
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The doc comment formatting here seems to have hit a snag.

src/lib.rs Outdated
///
/// You can either call this macro with no arguments `setup_panic!()` or
/// You can either call this macro with no arguments `setup_pan
/// #[cfg(feature = "nightly")]ic!()` or
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The doc comment formatting here seems to have hit a snag.

src/lib.rs Outdated

/// Utility function that prints a message to our human users

#[cfg(feature = "nightly")]/// Utility function that prints a message to our human users
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The doc comment formatting here seems to have hit a snag.

src/lib.rs Outdated
};

#[cfg(not(feature = "nightly"))]
let cause = String::from("Not supported by application");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should add slightly more context here? Seeing this message makes me ask the question of: "what isn't supported by the application?"

How about one of:

Error cause could not be determined by the application.
Failure cause could not be determined by the application.

Copy link
Collaborator

@yoshuawuyts yoshuawuyts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some comments!

@yoshuawuyts
Copy link
Collaborator

@spacekookie I think being able to report on nightly, rather than not at all seems reasonable. We can always move to upgrade from there once more functionality around this stabilizes.

If we decide to merge this patch we should probably open a new issue to move the same reporting to stable, and link it against any stabilization issues on rust-lang/rust so we can switch over once it stabilizes. ✨

@spacekookie
Copy link
Collaborator Author

Sounds good! Thanks for the review!

The doc comment things is really weird, I'll have a look at what might have happened there...

@spacekookie
Copy link
Collaborator Author

Ping @yoshuawuyts sorry for the delay, I fixed the issues in the code. No idea what caused the issue in the changelog, or how to fix it? What's the tool that is invoked there?

@spacekookie spacekookie changed the title Including original panic-cause in report Including original-sin (panic) in report Oct 4, 2018
@spacekookie
Copy link
Collaborator Author

I think I'll just rebase this against master once #49 lands 🎉

yoshuawuyts and others added 5 commits October 4, 2018 19:10
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 :)
@spacekookie spacekookie merged commit 920251c into master Oct 4, 2018
@spacekookie spacekookie deleted the original-panic branch October 4, 2018 17:34
@spacekookie spacekookie mentioned this pull request Oct 5, 2018
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Report contains less info than normal panic output

3 participants