Skip to content
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

Add features handle-panics and backtrace #421

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

target-san
Copy link

@target-san target-san commented Jan 21, 2024

  • handle-panics attempts to capture panic backtrace when one happens, instead of spitting it to console
  • backtrace enables actual backtraces using std::backtrace
  • Short backtrace printed second time after test failure is produced by toplevel test func reporting its failure via panic, can be remedied by rewriting helper macros so that they return failure instead of panicking.
  • Collected backtrace is still 50+ frames long. Unfortunately it seems to be impossible to even enumerate frames on stable, yet alone use existing short backtrace style. Backtrace::frames() and BacktraceFrame are still experimental.

P.S: Sorry for "PR spam", prev one #419 was closed prematurely due to accident

closes #356


static INIT_ONCE: Once = Once::new();
// NB: no need for external sync, value is mutated only once, when init is performed
static mut DEF_HOOK: Option<Box<dyn Fn(&PanicInfo<'_>) + Send + Sync>> =
Copy link
Contributor

Choose a reason for hiding this comment

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

please expand this to DEFAULT_HOOK for clarity, i'm concerned that "DEF" could be mistaken for something else

Copy link
Author

Choose a reason for hiding this comment

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

Done

@@ -210,6 +212,96 @@ where
})
}

#[cfg(feature = "handle-panics")]
mod panicky {
Copy link
Contributor

Choose a reason for hiding this comment

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

given the unsafe usage, this section could use a bit more documentation i think. possibly specifying what the responsibility of each static variable and each function as well as clarifying the order of operations. i don't think it needs to be long but just enough to provide more clarity

Copy link
Author

Choose a reason for hiding this comment

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

Done. Added more comments, doc comments for funcs and variables, and module-level doc comment with overall description of whole process

(Self::Fail(l0, _, l2), Self::Fail(r0, _, r2)) => {
l0 == r0 && l2 == r2
}
_ => false,
Copy link
Contributor

Choose a reason for hiding this comment

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

i think i'd prefer if we exhaustively match here, even if it's more verbose

Copy link
Author

Choose a reason for hiding this comment

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

Done

Copy link
Contributor

@rexmas rexmas left a comment

Choose a reason for hiding this comment

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

thank you for this pr, i think this will be a very nice addition :)

@target-san
Copy link
Author

target-san commented Mar 5, 2024

My biggest concern is that I had to change TestCaseError and TestError types to keep backtrace. This effectively breaks public API. Unfortunately making this change cfg-conditional isn't very appealing too, as it introduces conditional matches in unit tests.

@target-san target-san requested a review from rexmas March 5, 2024 10:31
Copy link
Contributor

@rexmas rexmas left a comment

Choose a reason for hiding this comment

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

thank you for the detailed docs, this looks great 👍

@rexmas
Copy link
Contributor

rexmas commented Mar 8, 2024

cc @matthew-russo

@matthew-russo
Copy link
Member

I had started going through this last night. will finish up later tonight

@rexmas
Copy link
Contributor

rexmas commented Mar 8, 2024

This effectively breaks public API.

Ah right, thank you for raising this. I don't think we can merge then until we move to a new major version unfortunately, or without making it a separate feature like you suggested, and yes I can see how that's unappealing.

@rexmas rexmas added the 2.0-wishlist This issue proposes breaking changes we'd like in a 2.0 release label Mar 8, 2024
@target-san
Copy link
Author

Ok, then I guess the best course is to take out "backtrace" feature and try introduce it as separate PR. Will do it in a few days.

@matthew-russo
Copy link
Member

we're looking at a 2.0 release so we can include this and a couple other things that are pending. it'd probably take 1-2 months to get everything together if those timelines work for you. also happy to accept changes with no backwards compatibility issues in the meantime if you want a faster turnaround

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.0-wishlist This issue proposes breaking changes we'd like in a 2.0 release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add backtraces in final error report
3 participants