feat: traceback integration - #6342
Conversation
davidhewitt
left a comment
davidhewitt
left a comment
There was a problem hiding this comment.
Oooh thanks, interesting!
| let format = traceback.format().expect("expected formatting to work"); | ||
| let file_path = PathBuf::from(file!()); | ||
| let file_name = file_path.file_name().and_then(|s| s.to_str()).unwrap(); | ||
| assert!(format.contains(file_name)); |
There was a problem hiding this comment.
I would love to see a more complete test of the full formatted traceback here!
| let err = PyRuntimeError::new_err(format!("{error:?}")); | ||
| #[cfg(all(not(Py_LIMITED_API), not(PyPy), not(GraalPy)))] | ||
| Python::try_attach(|py| { | ||
| if let Ok(tb) = error.backtrace().into_pyobject(py) { |
There was a problem hiding this comment.
I wonder, is it possible to somehow end up with nested Rust -> Python tracebacks in here? I suspect it'd be quite hard to extract that structure...
There was a problem hiding this comment.
I think so too, as std::backtrace objects can’t be manipulated (thus my addition of btparse).
I think we can at do a better job at “anyhow error that can be downcast to a PyErr” by stitching the tracebacks together.
I still need guidance for stable-eyre and color-eyre – they both use the crates.io backtrace library, which can be modified, so that would be possible.
There was a problem hiding this comment.
Looks great, and seems quite orthogonal to this PR. Of course whichever is merged first would mean the other could benefit from it.
3 participants
Fixes #1066
TODO: figure out how to do eyre support.
color-eyreandstable-eyrehave backtraces, but adding all that would add a bunch of features, so I’d welcome some guidance.