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
Current master (908cc43), probably all prior versions since addition of set_default.
Crates
tracing-core
Description
When a local default Dispatch is set, a guard is created which restores the previous Dispatch on drop. However, this does not take into account the possibility that the dropped guard may not be the last guard or that the Dispatch that is being restored may have had its guard already dropped.
For example if one calls set_default three times with guards a, b, and c, they should be using the dispatch guarded by c. If b is dropped now, the default Dispatch is restored back to the one behind the a guard.
I think that the latest Dispatch for which a guard was not dropped should be used. Tracking of the state will become more complex.
Alternatively, this could be ignored as it seems that no one has encountered this bug so far and the usage of set_default like this seems rather contrived.
The text was updated successfully, but these errors were encountered:
Bug Report
Version
Current master (908cc43), probably all prior versions since addition of
set_default
.Crates
tracing-core
Description
When a local default
Dispatch
is set, a guard is created which restores the previousDispatch
on drop. However, this does not take into account the possibility that the dropped guard may not be the last guard or that theDispatch
that is being restored may have had its guard already dropped.For example if one calls
set_default
three times with guardsa
,b,
andc
, they should be using the dispatch guarded byc
. Ifb
is dropped now, the defaultDispatch
is restored back to the one behind thea
guard.Example code reproduction
Proposal
I think that the latest
Dispatch
for which a guard was not dropped should be used. Tracking of the state will become more complex.Alternatively, this could be ignored as it seems that no one has encountered this bug so far and the usage of
set_default
like this seems rather contrived.The text was updated successfully, but these errors were encountered: