-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-fmtArea: `core::fmt`Area: `core::fmt`C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.WG-debuggingWorking group: Bad Rust debugging experiencesWorking group: Bad Rust debugging experiences
Description
This is technically not a bug, but simply a rather frustrating behavior. If you write dbg!(a, b)
, then the implementation doesn't take a lock on stderr
for the entire debug print, but for a
and b
separately. This means that they can tear with other (debug) prints on stderr. E.g. if you have
// Thread A.
let (a, b) = (1, 2);
dbg!(a, b);
// Thread B.
let (a, b) = (3, 4);
dbg!(a, b);
You can see the output (or various other interleavings, it gets worse with more statements and more threads)
[src/some/path.rs] a = 3
[src/some/path.rs] a = 1
[src/some/path.rs] b = 4
[src/some/path.rs] b = 2
A workaround is to use dbg!((a, b))
but I'd rather we just fix the implementation to take a lock once for the entire dbg!
call to make the entire debug print atomic.
MolotovCherry and Noratriebjyn514 and MolotovCherry
Metadata
Metadata
Assignees
Labels
A-fmtArea: `core::fmt`Area: `core::fmt`C-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.WG-debuggingWorking group: Bad Rust debugging experiencesWorking group: Bad Rust debugging experiences