remove FIXME block from has_significant_drop, it never encounters inference variables

[tnuha]

The FIXME block in Ty::has_significant_drop is outdated as related queries can now handle type inference.

rust/compiler/rustc_middle/src/ty/util.rs

Lines 1378 to 1389 in 321a89b

	// FIXME(#86868): We should be canonicalizing, or else moving this to a method of inference
	// context, or *something* like that, but for now just avoid passing inference
	// variables to queries that can't cope with them. Instead, conservatively
	// return "true" (may change drop order).
	if query_ty.has_infer() {
	return true;
	}
	// This doesn't depend on regions, so try to minimize distinct
	// query keys used.
	let erased = tcx.normalize_erasing_regions(typing_env, query_ty);
	tcx.has_significant_drop_raw(typing_env.as_query_input(erased))

Closes #86868 (other places mentioned in the issue have been resolved, or moved to other issues)

r? types

[compiler-errors]

Let's double check this with crater.

@bors2 try

[rust-bors]

⌛ Trying commit 75ec279 with merge 1383df0…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1383df0 (1383df06117fd218068d1f39fd5326256dd4a348, parent: ca77504943887037504c7fc0b9bf06dab3910373)

[compiler-errors]

@craterbot check

[craterbot]

👌 Experiment pr-145181 created and queued.
🤖 Automatically detected try build 1383df0
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-145181 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[compiler-errors]

[...] as related queries can now handle type inference.

I think the more likely thing here is that we're now being more responsible and only calling has_significant_drop on types that don't have infer vars.

[tnuha]

I did actually try this- the inference block I removed is certainly being hit in a few cases. I can rerun that experiment to find exactly which if you'd like.

Are you thinking the related queries still don't cope with infer vars? If so, do you know of a way to test this? (locally, not with craterbot ofc)

[tnuha]

@compiler-errors https://github.com/rust-lang/rust/blob/master/tests/incremental/issue-86753.rs is an example for where has_significant_drop is called with an infer var, although admittedly a complex one. Works fine with the block removed.

I do see an argument for favoring canonicalization regardless- I just see this as an avenue for reducing complexity. Whatever seems to be the most appropriate.

[craterbot]

🎉 Experiment pr-145181 is completed!
📊 12 regressed and 6 fixed (679566 total)
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[tnuha]

r? @compiler-errors

[rustbot]

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

[compiler-errors]

r? lcnr

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tnuha]

@craterbot check