Remove all json handling from rustc_serialize

[bjorn3]

Json is now handled using serde_json. Where appropriate I have replaced json usage with binary serialization (rmeta files) or manual string formatting (emcc linker arg generation).

This allowed for removing and simplifying a lot of code, which hopefully results in faster serialization/deserialization and faster compiles of rustc itself.

Where sensible we now use serde. Metadata and incr cache serialization keeps using a heavily modified (compared to crates.io) rustc-serialize version that in the future could probably be extended with zero-copy deserialization or other perf tricks that serde can't support due to supporting more than one serialization format.

Note that I had to remove -Zast-json and -Zast-json-noexpand as the relevant AST types don't implement serde::Serialize.

Fixes #40177

See also rust-lang/compiler-team#418

[rust-highfive]

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit a5c45c2d6b6cb76b849ffc51be5de6c195c949c1 with merge 8b3e2e37129e9123c00dc4170c440c0c0b5dc51b...

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit b037d152bc6fc039a192cee277f094e968143ce4 with merge a0d810daa8d1883f9c5ce417226f96be2b28e2d7...

[bjorn3]

@bors try-

[bjorn3]

@bors r- retry

[bjorn3]

@rust-timer build a0d810daa8d1883f9c5ce417226f96be2b28e2d7

[rust-timer]

Queued a0d810daa8d1883f9c5ce417226f96be2b28e2d7 with parent 595088d, future comparison URL.

[jyn514]

cc rust-lang/compiler-team#418

[rust-timer]

Finished benchmarking try commit (a0d810daa8d1883f9c5ce417226f96be2b28e2d7): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[bjorn3]

Rebased

@bors r=wesleywiser

[bors]

📌 Commit 5cc3593 has been approved by wesleywiser

[bors]

⌛ Testing commit 5cc3593 with merge 7e9b92c...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 7e9b92c to master...

[rust-timer]

Finished benchmarking commit (7e9b92c): comparison url.

Instruction count

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: mixed results

	mean1	max	count2
Regressions 😿 (primary)	0.5%	1.3%	68
Regressions 😿 (secondary)	0.9%	3.5%	40
Improvements 🎉 (primary)	-0.4%	-0.6%	3
Improvements 🎉 (secondary)	-0.5%	-1.0%	24
All 😿🎉 (primary)	0.5%	1.3%	71

Max RSS (memory usage)

Results

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: 😿 relevant regressions found

	mean1	max	count2
Regressions 😿 (primary)	3.0%	3.1%	2
Regressions 😿 (secondary)	3.8%	5.0%	2
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	3.0%	3.1%	2

Cycles

Results

• Primary benchmarks: 😿 relevant regressions found
• Secondary benchmarks: no relevant changes found

	mean1	max	count2
Regressions 😿 (primary)	2.4%	2.8%	2
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	2.4%	2.8%	2

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩² ↩³

2. number of relevant changes ↩ ↩² ↩³

[nnethercote]

I was unable to reproduce the perf regressions in a local build. Some of the benchmarks in question (e.g. cranelift-codegen-0.82.1, keccak) are sensitive to small changes in codegen in and around process_obligations, I wonder if something happened there. Hopefully it's just noise and will shift back at some point?