Added codegen tests for different forms of Option::or

[rwardd]

Adds tests to check the output of the different ways of writing Option::or

Fixes #124533

[rustbot]

Mark-Simulacrum is not on the review rotation at the moment.
They may take a while to respond.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

[scottmcm]

r? scottmcm

[scottmcm]

Thanks for picking up this work!

Looking mostly good; I left some comments. The DAG one I do feel reasonably strongly about. The others think about and feel free to push back if you think otherwise.

View changes since this review

[rustbot]

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

[rwardd]

The DAG one I do feel reasonably strongly about. The o

Thank you very much for the valuable feedback - I agree with all the comments, and have attempted to address and implement all of it. I have two further questions:

1. If/when this PR gets approved, are you happy if the same style is followed to build out the Option::and and Result::{and, or} tests? E.g., have multiple functions for the different forms of the operation, and test them against the three types (u8, [u8; 1], NonZero<u8>) as was done in this PR?

2. Is there value in writing tests for larger types (e.g. u64, [u64; 1] ...)? I am cognisant of keeping tests minimal as stated in the Best Practices section, and don't want to inflate the tests if they are superfluous.

Thanks again!

[rwardd]

@rustbot ready

[scottmcm]

1. Yes, this same style makes sense to me.
2. Unless there's a particular reason to think they'll do something different, I'd prefer fewer tests overall. LLVM support arbitrary-sized integer types (even i40 and such), which means it's usually pretty reliable at not doing something different just because it's a wider integer type. If you play around and notice a difference that's interesting, then sure, but hopefully the "what's the BackendRepr variant of the option" coverage is getting the interesting differences and thus different widths (or floats, or ...) aren't interesting enough to bother testing separately. (Unless, of course, someone finds an issue about them.)

[rwardd]

@rustbot ready

Thank you very much again for feedback (and patience!). I've implemented all the suggestions (specifically ensuring all ret comments are actually CHECKed), and gone ahead and extended some of the existing CHECKs to be more explicit with argument naming and return values.

[scottmcm]

Thanks, this looks great! Welcome to the never-as-simple-as-you'd-wish world of codegen tests :P

@bors r+ rollup=iffy (new codegen tests are always a different-target risk)

[bors]

📌 Commit a2fcb0d has been approved by scottmcm

It is now in the queue for this repository.

[bors]

⌛ Testing commit a2fcb0d with merge 860bfa3...

[rust-log-analyzer]

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

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

failures:

---- [ui] tests/ui/reachable/issue-948.rs stdout ----

error: error pattern 'beep boop' not found!
status: exit status: 101
command: RUSTC="/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" RUST_TEST_THREADS="4" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-client" "run" "0" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/reachable/issue-948/a"
--- stdout -------------------------------
uploaded "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/reachable/issue-948/a", waiting for result
------------------------------------------

[bors]

💔 Test failed - checks-actions

[scottmcm]

@bors retry (no way that adding one codegen test broke a ui test)

[bors]

⌛ Testing commit a2fcb0d with merge f57b9e6...

[bors]

☀️ Test successful - checks-actions
Approved by: scottmcm
Pushing f57b9e6 to main...

[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 7ecabfa (parent) -> f57b9e6 (this PR)

Test differences

Show 4 test diffs

Stage 1

• [codegen] tests/codegen-llvm/issues/multiple-option-or-permutations.rs: [missing] -> pass (J0)

Stage 2

• [codegen] tests/codegen-llvm/issues/multiple-option-or-permutations.rs: [missing] -> pass (J1)

Additionally, 2 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: pr-check-2, x86_64-gnu-llvm-20-3, x86_64-gnu-llvm-21-3
• J1: aarch64-apple, aarch64-gnu, aarch64-gnu-llvm-20-1, aarch64-msvc-1, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-gnu, x86_64-gnu-llvm-20-2, x86_64-gnu-llvm-21-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard f57b9e6f565a1847e83a63f3e90faa3870536c1f --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-riscv64-linux: 6053.6s -> 4776.2s (-21.1%)
2. i686-msvc-1: 10761.3s -> 9662.4s (-10.2%)
3. x86_64-msvc-1: 9440.8s -> 8514.6s (-9.8%)
4. x86_64-msvc-2: 8066.6s -> 8790.3s (+9.0%)
5. x86_64-gnu: 7543.0s -> 8209.4s (+8.8%)
6. dist-x86_64-apple: 7530.0s -> 6885.8s (-8.6%)
7. tidy: 156.1s -> 169.1s (+8.3%)
8. x86_64-rust-for-linux: 2710.6s -> 2514.3s (-7.2%)
9. dist-i686-linux: 6468.8s -> 6022.2s (-6.9%)
10. dist-aarch64-llvm-mingw: 5967.7s -> 5567.0s (-6.7%)

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 (f57b9e6): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

Cycles

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

Binary size

Results (primary 0.0%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.0%	[0.0%, 0.1%]	16
Regressions ❌ (secondary)	0.1%	[0.0%, 0.1%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.0%	[0.0%, 0.1%]	16

Bootstrap: 475.226s -> 474.455s (-0.16%)
Artifact size: 390.78 MiB -> 390.84 MiB (0.01%)