Reuse the index from promoted nodes when coloring executed tasks

[Zoxc]

#138824 did not correctly handle the case where a dep node was promoted green, but later or concurrently executed. It resulted in multiple dep nodes being allocated to it. This fixes that by checking that the node was not previously green in the encoder lock.

This also fixes a race when forcing diagnostic nodes introduced in #138824.

#138824 should get reverted on beta.

This should fix #139110.

r? @oli-obk

[oli-obk]

@bors r+ rollup=never

[bors]

📌 Commit 1c568bb has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1c568bb with merge e62d47d...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing e62d47d to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 0fe8f34 (parent) -> e62d47d (this PR)

Test differences

No test diffs found

Job duration changes

1. dist-x86_64-apple: 10668.2s -> 8833.8s (-17.2%)
2. dist-apple-various: 7335.0s -> 6335.0s (-13.6%)
3. dist-aarch64-apple: 5210.3s -> 4700.0s (-9.8%)
4. x86_64-apple-2: 5540.7s -> 5133.1s (-7.4%)
5. x86_64-apple-1: 8539.6s -> 7937.7s (-7.0%)
6. dist-aarch64-msvc: 8043.2s -> 8597.6s (6.9%)
7. dist-x86_64-illumos: 6101.2s -> 5751.8s (-5.7%)
8. mingw-check: 1301.5s -> 1248.7s (-4.1%)
9. dist-i586-gnu-i586-i686-musl: 5231.8s -> 5022.8s (-4.0%)
10. arm-android: 5371.0s -> 5578.7s (3.9%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (e62d47d): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results (primary -4.2%)

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)	-	-	0
Improvements ✅ (primary)	-4.2%	[-4.2%, -4.2%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-4.2%	[-4.2%, -4.2%]	1

Cycles

Results (primary 1.3%, secondary -1.2%)

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)	1.3%	[0.8%, 1.6%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	1.3%	[0.8%, 1.6%]	3

Binary size

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

Bootstrap: 781.425s -> 782.4s (0.12%)
Artifact size: 365.92 MiB -> 365.96 MiB (0.01%)