Disable drop range tracking in generators

[eholk]

Generator drop tracking caused an ICE for generators involving the Never type (Issue #93161). Since this breaks a test case with miri, we temporarily disable drop tracking so miri is unblocked while we properly fix the issue.

[rust-highfive]

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

[eholk]

r? @RalfJung

I went ahead and put this PR up in case we need a quick fix to the issue, since the original PR is large and would be hard to revert. I'll leave it up to you, @RalfJung, if we want to merge it. I'll look into a proper fix today. I suspect it will be pretty straightforward, but I haven't looked at it yet.

[RalfJung]

FWIW this does not just break Miri, it breaks rustc as well. rustc just does not have a testcase that triggers the ICE, it seems. But I see you added one. :)

So, disabling that if is safe, the rest of the generator pass will still work correctly? I don't know this code at all so I cannot really evaluate this. But generally I agree disabling this until the ICE is fixed makes sense.

Cc @nikomatsakis who reviewed #91032

[nikomatsakis]

@bors r+

[bors]

📌 Commit ead84d0 has been approved by nikomatsakis

[eholk]

I updated the PR description to mention that this breaks one of the miri test cases, to hopefully make it clearer that rustc breaks in the same way.

Disabling the if is safe because the if only prunes types from appearing in the generator. It's okay to over-approximate, but under-approximating is a problem (that's why this test case is failing). Disabling the if still does all the analysis to determine if we can prune the type, but doesn't actually do anything with it, so we'll have the same behavior even if we do some extra work.

[matthiaskrgr]

@bors p=1 since we are getting several reports about the ICE already

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

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

[RalfJung]

@bors retry Could not resolve host: ci-mirrors.rust-lang.org

[bors]

⌛ Testing commit ead84d0 with merge d13e8dd...

[bors]

☀️ Test successful - checks-actions
Approved by: nikomatsakis
Pushing d13e8dd to master...

[rust-highfive]

📣 Toolstate changed by #93165!

Tested on commit d13e8dd.
Direct link to PR: #93165

🎉 miri on linux: test-fail → test-pass (cc @RalfJung @oli-obk @eddyb).

[rust-timer]

Finished benchmarking commit (d13e8dd): comparison url.

Summary: This change led to very large relevant regressions 😿 in compiler performance.

• Very large regression in instruction counts (up to 879.2% on full builds of deeply-nested-async check)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[lqd]

At least these perf results make clear that #91032 was indeed the source of the -89.5% perf results for the rollup in which it landed.

This PR soft reverts it, negating the original change.

@rustbot label: +perf-regression-triaged