You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The panic that is being swallowed is not within the closure that is wrapped in catch_unwind. I think the issue here is that the panic hook is global, and so if you're running tests concurrently, one thread might install the custom panic hook for its catch_unwind call while another thread is in the middle of e.g. this parse operation that might fail.
…15319)
This fixes#15317. Our `catch_unwind` wrapper installs a panic hook that
captures (the rendered contents of) the panic info when a panic occurs.
Since the intent is that the caller will render the panic info in some
custom way, the hook silences the default stderr panic output.
However, the panic hook is a global resource, so if any one thread was
in the middle of a `catch_unwind` call, we would silence the default
panic output for _all_ threads.
The solution is to also keep a thread local that indicates whether the
current thread is in the middle of our `catch_unwind`, and to fall back
on the default panic hook if not.
## Test Plan
Artificially added an mdtest parse error, ran tests via `cargo test -p
red_knot_python_semantic` to run a large number of tests in parallel.
Before this patch, the panic message was swallowed as reported in
#15317. After, the panic message was shown.
Following #15241, some of the internal error messages from
red_knot_test
are now swallowed by the framework, for example this one here:ruff/crates/red_knot_test/src/lib.rs
Lines 32 to 37 in b264489
On a PR branch I was working on, I got this (not very informative!) test failure:
If I revert 75015b0 on that PR branch, I get this instead, which is much more helpful:
The text was updated successfully, but these errors were encountered: