[EXPERIMENT] Don't actually erase query values

[Zalathar]

This is a perf experiment to see what happens if we tweak the query system's value erasure mechanism to not actually erase anything.

The idea is to simulate what would happen if we removed erasure completely.

r? ghost

[Zalathar]

@bors try @rust-timer queue

[rust-bors]

💔 Test for 340e234 failed: CI. Failed job:

• try - dist-x86_64-linux (web logs, enhanced plaintext logs)

[Zalathar]

Looks like value erasure is accidentally load-bearing for satisfying various auto-trait bounds throughout the compiler, so simply turning it off is a non-trivial task.

[Zalathar]

@bors try @rust-timer queue

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

REPOSITORY                                   TAG       IMAGE ID       CREATED      SIZE
ghcr.io/dependabot/dependabot-updater-core   latest    354d02aa29ac   7 days ago   783MB
=> Removing docker images...
Deleted Images:
untagged: ghcr.io/dependabot/dependabot-updater-core:latest
untagged: ghcr.io/dependabot/dependabot-updater-core@sha256:596da3f22bcbdff2c96fd7126001278022c834c1621c5efa2ad1a7794590636c
deleted: sha256:354d02aa29acf525570c732b6e006ecf138de6d63ca525d552eb4b24880ddc6c
deleted: sha256:8b7af0e426bc2cbeeacfd96b8354d3b80016991520977197e62090e47abaede8
deleted: sha256:cadf11ef1de7fdd5eab563757942353684047f09b212dc99d6ed48e8acf34d62
deleted: sha256:569b0caf9d5285db44ccd2629a3470139eea755be423a33a54d8a24cb3926bfa
deleted: sha256:f9dc5feb048d8f9fd43137e3998f59e9acfbd76c47a4e14984d109654119e282
---
tests/ui/drop_non_drop.rs ... ok
tests/ui/duplicate_underscore_argument.rs ... ok
tests/ui/double_parens.rs ... ok
tests/ui/duplicated_attributes.rs ... ok
tests/ui/duration_suboptimal_units_days_weeks.rs ... ok
tests/ui/duration_suboptimal_units.rs ... ok
tests/ui/duration_subsec.rs ... ok
tests/ui/duration_suboptimal_units_days_weeks.fixed ... ok
tests/ui/double_parens.fixed ... ok
tests/ui/duration_suboptimal_units.fixed ... ok
tests/ui/duration_subsec.fixed ... ok
tests/ui/eager_transmute.rs ... ok
tests/ui/empty_docs.rs ... ok
---
...............................................    (147/147)

======== tests/rustdoc-gui/globals.goml ========

[ERROR] line 14: The following errors happened: [Property named `"searchIndex"` doesn't exist]: for command `assert-window-property-false: {"searchIndex": null}`
    at <file:///checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/test_docs/index.html?search=Foo>

======== tests/rustdoc-gui/search-result-display.goml ========

[WARNING] line 39: Delta is 0 for "x", maybe try to use `compare-elements-position` instead?

[rust-bors]

☀️ Try build successful (CI)
Build commit: 71ec6d2 (71ec6d2d525d8fdce680c8240c13411dc624323c, parent: b3cda168c8afd5c4240a9477f6a7f54e70e2589a)

[rust-timer]

Finished benchmarking commit (71ec6d2): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.4%	[0.0%, 0.8%]	22
Improvements ✅ (primary)	-0.3%	[-0.6%, -0.1%]	78
Improvements ✅ (secondary)	-0.3%	[-1.1%, -0.0%]	74
All ❌✅ (primary)	-0.3%	[-0.6%, -0.1%]	78

Max RSS (memory usage)

Results (primary 1.6%, secondary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.7%	[0.4%, 6.7%]	123
Regressions ❌ (secondary)	2.4%	[0.5%, 6.2%]	136
Improvements ✅ (primary)	-4.2%	[-4.6%, -3.8%]	2
Improvements ✅ (secondary)	-3.5%	[-3.5%, -3.5%]	1
All ❌✅ (primary)	1.6%	[-4.6%, 6.7%]	125

Cycles

Results (secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.5%	[2.6%, 6.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.6%	[-3.9%, -1.7%]	5
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 472.506s -> 493.944s (4.54%)
Artifact size: 383.60 MiB -> 391.85 MiB (2.15%)

[rust-bors]

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

[Zalathar]

Closing this as a completed experiment; we can open a new PR if we want to actually make this change.

EDIT: The bootstrap-time and artifact-size regressions are big enough that we should probably lean towards keeping value-erasure.

[petrochenkov]

Hmm, does Erased<T> by any chance implement Send/Sync when T does not? It probably shouldn't.

[Zalathar]

It's backed by [u8; N], so it probably does, yeah.

We should probably have some auto-trait bounds on Erased<T> to rule that out.

[lqd]

I don't have a link handy to the PR which introduced this change, but you can see in the results above the additional 8MB of code and time it takes to build rustc.

[Zalathar]

I don't have a link handy to the PR which introduced this change, but you can see in the results above the additional 8MB of code and time it takes to build rustc.

Yeah, the bootstrap-time and artifact-size regressions are big enough that this isn’t necessarily something we’d want to do.