Fix #[expect(dead_code)] liveness propagation

[mu001999]

Fixes #154324
Fixes #152370 (cc @eggyal)

Previously, when traversing from a ComesFromAllowExpect::Yes item (i.e., with #[allow(dead_code)] or #[expect(dead_code)]), other ComesFromAllowExpect::Yes items reached during propagation would be updated to ComesFromAllowExpect::No and inserted into live_symbols. That caused dead_code lint couldn't be emitted correctly.

After this PR, ComesFromAllowExpect::Yes items no longer incorrectly update other ComesFromAllowExpect::Yes items during propagation or mark them live by mistake, then dead_code lint could behave as expected.

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 12 candidates

[mu001999]

@rustbot author

I realized that this would fail during secondary propagation. This still needs to be revised a bit.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[mu001999]

oops, forgot to update the label

@rustbot ready

[joshtriplett]

See #152370 (comment) .

[joshtriplett]

Test cases look good here.

[mu001999]

@rustbot reroll

[TaKO8Ki]

Sorry. I overlooked this pr.

View changes since this review

[TaKO8Ki]

r? TaKO8Ki @bors r+ rollup

[rust-bors]

📌 Commit faa7966 has been approved by TaKO8Ki

It is now in the queue for this repository.

[Mark-Simulacrum]

@rust-timer build 40d0e95

[rust-timer]

Finished benchmarking commit (40d0e95): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@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)	1.0%	[0.3%, 2.1%]	14
Regressions ❌ (secondary)	0.7%	[0.6%, 0.7%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	3
All ❌✅ (primary)	1.0%	[0.3%, 2.1%]	14

Max RSS (memory usage)

Results (primary 0.1%, secondary 3.1%)

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

	mean	range	count
Regressions ❌ (primary)	2.3%	[2.3%, 2.3%]	1
Regressions ❌ (secondary)	3.1%	[3.1%, 3.1%]	1
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.1%	[-2.0%, 2.3%]	2

Cycles

Results (primary 2.8%, secondary 5.6%)

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

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 492.256s -> 491.986s (-0.05%)
Artifact size: 394.33 MiB -> 394.36 MiB (0.01%)

[Mark-Simulacrum]

Looks like this caused some regressions, including outside incremental scenarios. I think since it's a correctness fix it's probably acceptable, marking as triaged. I suspect most of the regressions are predominantly just in instruction count based on the changes -- since we're moving slightly larger structs around that'll take a few extra instructions -- but that shouldn't take meaningfully more wall time, which aligns with minimal cycle count changes.