Ensure test library issues json string line-by-line

[raoulstrackx]

#108659 introduces a custom test display implementation. It does so by using libtest to output json. The stdout is read line by line and parsed. The code trims the line read and checks whether it starts with a { and ends with a }.

Unfortunately, there is a race condition in how json data is written to stdout. The write_message function calls self.out.write_all repeatedly to write a buffer that contains (partial) json data, or a new line. There is no lock around the self.out.write_all functions. Similarly, the write_message function itself is called with only partial json data. As these functions are called from concurrent threads, this may result in json data ending up on the same stdout line. This PR avoids this by buffering the complete json data before issuing a single self.out.write_all.

(#109484 implemented a partial fix for this issue; it only avoids that failed json parsing would result in a panic.)

cc: @jethrogb, @pietroalbini

[rustbot]

r? @cuviper

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[raoulstrackx]

r? @pietroalbini could you review?

[pietroalbini]

The approach looks great! A few calls can be simplified though, left a comment on one of them.

[raoulstrackx]

@pietroalbini when you have time, can you have another look at this PR? Thank you!

[bors]

☔ The latest upstream changes (presumably #110643) made this pull request unmergeable. Please resolve the merge conflicts.

[raoulstrackx]

Can this have a review please?

[pietroalbini]

Sorry for the delay!

@bors r+ rollup=iffy

[bors]

📌 Commit a18b750 has been approved by pietroalbini

It is now in the queue for this repository.

[bors]

⌛ Testing commit a18b750 with merge b4571be...

[bors]

☀️ Test successful - checks-actions
Approved by: pietroalbini
Pushing b4571be to master...

[rust-timer]

Finished benchmarking commit (b4571be): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.7%	[-0.7%, -0.7%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-3.3%	[-3.3%, -3.3%]	1
Improvements ✅ (secondary)	-2.5%	[-3.3%, -2.1%]	3
All ❌✅ (primary)	-3.3%	[-3.3%, -3.3%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 656.048s -> 657.453s (0.21%)