Some let chains clean-up

[Kivooeo]

Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one

r? compiler

[rustbot]

Some changes occurred to constck

cc @fee1-dead

Some changes occurred in match checking

cc @Nadrieril

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

HIR ty lowering was modified

cc @fmease

Some changes occurred in compiler/rustc_codegen_ssa/src/codegen_attrs.rs

cc @jdonszelmann

[SparrowLii]

Thanks for your work! Could you split the change to a few commits to make it easier for review(and for merging)?

[Kivooeo]

Well, I've found some time, did you mean to split commits like this (I'll reword them later if needed)? Or like... different PRs?

[SparrowLii]

One PR is enough. But TBH I don't see some real benefit from doing these clean-ups, since they don't significantly reduce the number of lines of code. And it may change the logic of the original design. For example, developers may add some else statements in the future

[Kivooeo]

Originally idea come up from this two

66ea349

ccbe983

and such other PRs that I saw before from different people that refactor few places to use let chains instead of nesting

[SparrowLii]

OK. From this point of view, instead of thinking "why do this", maybe it is better to answer "why not do this" :)
I still advice you separate this PR into several commits(according to the distribution of code functionality). After all, we don't have an automated tool to check whether the conversion from nesting to let-chain is correct. This makes it easier to locate problems (and review)

[Kivooeo]

@SparrowLii I'm pretty sure I've splitted this PR already into separate commits, this one is 3 commits instead of 1. If you meant something different by splitting PR please could you explain then

[SparrowLii]

Please make the commits' description more meaningful (like use let-chains in AST/HIR/MIR...) then we can merge it

[Kivooeo]

Should I also squash them?

[SparrowLii]

Without squashing. These commit descriptions are what we will display in the git log.

[Kivooeo]

Hope this ones are fine, it's pretty hard to come up with something very descriptive, so I just used your idea

[SparrowLii]

@bors r+ rollup=never

[bors]

📌 Commit b8eb046 has been approved by SparrowLii

It is now in the queue for this repository.

[bors]

⌛ Testing commit b8eb046 with merge d242a8b...

[bors]

☀️ Test successful - checks-actions
Approved by: SparrowLii
Pushing d242a8b 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 733dab5 (parent) -> d242a8b (this PR)

Test differences

Show 23 test diffs

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

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard d242a8bd5a73f633ba1ec5aacf19acf35a3c747d --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-aarch64-linux: 5796.6s -> 8372.6s (44.4%)
2. x86_64-apple-2: 4738.3s -> 6836.7s (44.3%)
3. aarch64-apple: 5538.2s -> 7092.1s (28.1%)
4. dist-apple-various: 6509.3s -> 7742.5s (18.9%)
5. x86_64-gnu-tools: 4261.2s -> 3722.0s (-12.7%)
6. dist-aarch64-msvc: 6072.2s -> 5324.2s (-12.3%)
7. dist-aarch64-apple: 6187.2s -> 6899.2s (11.5%)
8. dist-i586-gnu-i586-i686-musl: 5519.8s -> 5966.8s (8.1%)
9. dist-x86_64-apple: 10796.9s -> 11534.9s (6.8%)
10. dist-x86_64-mingw: 7947.3s -> 7495.6s (-5.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 (d242a8b): 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 1.6%, secondary -1.1%)

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

	mean	range	count
Regressions ❌ (primary)	1.6%	[1.6%, 1.6%]	1
Regressions ❌ (secondary)	2.4%	[2.4%, 2.4%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.6%	[-4.6%, -4.6%]	1
All ❌✅ (primary)	1.6%	[1.6%, 1.6%]	1

Cycles

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

Binary size

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

Bootstrap: 466.742s -> 465.115s (-0.35%)
Artifact size: 376.83 MiB -> 376.87 MiB (0.01%)