new lint: [or_else_then_unwrap]

[illicitonion]

changelog: [or_else_then_unwrap]: New lint. This is the same as or_then_unwrap but for or_else calls with a closure immediately calling Some.

[rustbot]

r? @llogiq

rustbot has assigned @llogiq.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ada4a]

Looking pretty good:) Left some minor comments

View changes since this review

[ada4a]

No idea how likely this is, but you could add a check for the Ok/Some coming from a macro expansion -- e.g., the user can't really do anything about a case like:

fn main() {
    macro_rules! some { () => { Some(5) } };
    None.or_else(|| some!()).unwrap();

See this section for more info: https://doc.rust-lang.org/clippy/development/macro_expansions.html#spanctxt-method

[illicitonion]

I put in a test case for this with proc_macros::external!{ and it doesn't appear to be triggering the lint without adding in_external_macro check... I'd like to understand why that is before adding the code to intentionally avoid - any idea why this would be getting ignored already? Is that test the right approach, or is there e.g. something special to know about proc_macros::external?

[ada4a]

Ah, right, that's because methods/mod.rs mostly filters out any method calls coming from an expansion:

rust-clippy/clippy_lints/src/methods/mod.rs

Lines 4970 to 4972 in 95dd88d

	fn check_methods<'tcx>(&self, cx: &LateContext<'tcx>, expr: &'tcx Expr<'_>) {
	// Handle method calls whose receiver and arguments may not come from expansion
	if let Some((name, recv, args, span, call_span)) = method_call(expr) {

rust-clippy/clippy_lints/src/methods/mod.rs

Lines 4852 to 4864 in 95dd88d

	/// Extracts a method call name, args, and `Span` of the method name.
	/// This ensures that neither the receiver nor any of the arguments
	/// come from expansion.
	pub fn method_call<'tcx>(recv: &'tcx Expr<'tcx>) -> Option<(Symbol, &'tcx Expr<'tcx>, &'tcx [Expr<'tcx>], Span, Span)> {
	if let ExprKind::MethodCall(path, receiver, args, call_span) = recv.kind
	&& !args.iter().any(|e| e.span.from_expansion())
	&& !receiver.span.from_expansion()
	{
	Some((path.ident.name, receiver, args, path.ident.span, call_span))
	} else {
	None
	}
	}

This might change in the future, but for now, the check I was talking about is indeed unnecessary.

[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.

[illicitonion]

Thanks so much for the suggestions @ada4a, I really appreciate them!

I do want to call out - I pretty much copied this directly from the or_then_unwrap lint, so all of your suggestions probably apply there too. I'm happy to put together a PR updating that when we're happy with this one too. I did originally look for ways to try to share code between the two, but it felt like that would be more complicated than it was worth, but I'm happy to take another look if you'd prefer (particularly if you have any suggestions for how to make that work well!) :)

[ada4a]

Glad to have helped @illicitonion :)

I took a look at or_then_unwrap -- I think you're right unifying the logic wouldn't be worth it. And yes, a PR applying the suggestions to that lint as well would be very welcome:)