Let qualify_min_const_fn deal with drop terminators

[y21]

Fixes #12677

The method_accepts_droppable check that was there seemed overly conservative.

Returns true if any of the method parameters is a type that implements Drop.
The method can't be made const then, because drop can't be const-evaluated.

Accepting parameters that implement Drop should still be fine as long as the parameter isn't actually dropped, as is the case in the linked issue where the droppable is moved into the return place. This more accurate analysis ("is there a drop terminator") is already done by qualify_min_const_fn here, so I don't think this additional check is really necessary?

Fixing the other, second case in the linked issue was only slightly more involved, since Vec::new() is a function call that has the ability to panic, so there must be a drop() terminator for cleanup, however we should be able to freely ignore that. Const checking ignores cleanup blocks, so we should, too?

r? @Jarcho

---

changelog: [missing_const_for_fn]: continue linting on fns with parameters implementing Drop if they're not actually dropped

[y21]

I do wonder what

rust-clippy/clippy_lints/src/missing_const_for_fn.rs

Lines 154 to 158 in f5e2501

	if let Err((span, err)) = is_min_const_fn(cx.tcx, mir, &self.msrv) {
	if cx.tcx.is_const_fn_raw(def_id.to_def_id()) {
	cx.tcx.dcx().span_err(span, err);
	}
	} else {

is for... That seems like dead code essentially. We are early-returning if already_const before this, so I don't see how is_const_fn_raw() could be true.

[bors]

☔ The latest upstream changes (presumably #12713) made this pull request unmergeable. Please resolve the merge conflicts.