Add extensive set of drop order tests

[traviscross]

On lang, we've recently been discussing the drop order with respect to let chains apropos of how we shortened temporary lifetimes in Rust 2024 and how we may shorten them further in the future.

Here we add an extensive set of tests that demonstrate the drop order in the cases that interest us.

Regarding the let chains stabilization prompting this analysis, see:

• Stabilize let chains in the 2024 edition #132833

r? ghost

cc @ehuss @dingxiangfei2009 @nikomatsakis

[traviscross]

@dingxiangfei2009: This set of tests fails on run-rustfix due to the machine-applicable lints not successfully migrating all the code. Is this expected, and is there anything that might be done?

[traviscross]

Originally, this had...

#![cfg_attr(e2021, warn(rust_2024_compatibility))]

...but this was causing a different number of warnings to be generated in the CI llvm-18 test from what I could reproduce (or bless) in testing locally. It was a "nice to have", so I'm removed it for now to make this PR ready and to land these tests.

Similarly, this originally had...

//@ [e2021] run-rustfix

...but the automated lints don't migrate all the code, so it fails since there are still diagnostics emitted in the fixed version. It too was a "nice to have", so I've similarly removed it.

Both of these could be added back in separate PRs later.

[traviscross]

r? @compiler-errors

[dingxiangfei2009]

@traviscross They did not apply intentionally because migrating spans inside macro is considered "risky" and error-prone. The suggestion might apply but we won't know for sure if the macro would do something entirely different. I hope this still remains a reasonable compromise.

[traviscross]

@dingxiangfei2009: Thanks. I've updated the test to remove use of cfg_match!. Combined with rustfix-only-machine-applicable, that solves the run-rustfix issue.

One last issue:

My local build produces 15 warnings, and so that's what I get when blessing the test. But the CI sees 10 warnings. This is fully rebased, and using stage 2 to run the test. Any idea what might be causing this?

[traviscross]

Specifically, the CI seems to not be emitting the tail_expr_drop_order warnings.

[dingxiangfei2009]

CI tests enables a --pass=test flag to the compiletest. Without this flag, tail_expr_drop_order is properly linting. What confuses me at the moment is that essentially both if_let_rescope and tail_expr_drop_order use the same mechanism to decide the level.

I am investigating.

[dingxiangfei2009]

The --pass flag tries to override the test mode, say from a //@ run-pass test to a check test for instance, when applies.

I have a theory.

The test mode only changes when --pass=check is passed to ./x.py and eventually to compiletest. What this flag means to compiletest is that --emit=metadata is passed to rustc invocations. This happens in TestCx::should_emit_metadata. For this test to effect, the compilation pipeline needs to progress past the borrow-checking phase. Could this option inadvertently suppresses the lints because it bails out the compilation early?

Follow-up: Yes, dropping --emit=metadata gets us back the missing warnings.

[traviscross]

@jieyouxu: What do you think about the situation above with respect to compiletest?

[jieyouxu]

I'll take a look in a bit

[jieyouxu]

@dingxiangfei2009 your analysis is spot on.
@traviscross so usually build-pass and run-pass tests are also expected to check-pass, but in this scenario the lint has some specific behavior which is only available past --emit=metadata. This means that the emission will not be available if it's limited to check-pass a.k.a. --emit=metadata, if forcefully requested on a CI job via --pass=check.

You can use

// Lints are emitted past the borrow-checking phase, i.e. unavailable in
// `--pass=check`.
//@ ignore-pass

to instruct compiletest to not respect --pass=check for this test.

[traviscross]

@rustbot ready

[esote]

Hi, it looks like this PR is only waiting on review at this point, or is it blocked on something? Just checking in since I'd love to see #132833 make it into the 2024 edition (if that's still the plan)

[est31]

@esote yes I think this is blocked on review only now. But there is other real blockers for #132833 as well. The 2024 edition will ship without let chains (it's less than 7 weeks until when it's released), but the breaking changes we need are already in place so we'll just stabilize whenever the blockers unblock (and then on edition 2024+ only).