Add single_option_map lint

[yusufraji]

Checks for functions with method calls to .map(_) on an arg of type Option as the outermost expression.

Fixes #774

changelog: [`single_option_map`]: Checks for functions with method calls to `.map(_)` on an arg of type `Option` as the outermost expression.

[rustbot]

r? @Manishearth

rustbot has assigned @Manishearth.
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

[yusufraji]

r? @llogiq

[samueltardieu]

It is also necessary to check that the receiver of map() is the function parameter. Otherwise, the lint will trigger on code such as:

fn f(x: &str) -> Option<u32> {
    x.parse::<u32>().ok().map(|x| x+1)
}

[samueltardieu]

This test case should be added, to reflect one problem the lint had in its earlier form:

// No lint: maps other than the receiver
fn map_not_arg(arg: Option<u32>) -> Option<u32> {
    maps_static_option().map(|_| arg.unwrap())
}

Also, wrapping a function can be done more explicitly than with just the function name:

// No lint: wrapper function with η-expanded form
fn manipulate_opt_explicit(opt_i: Option<i32>) -> Option<i32> {
    opt_i.map(|x| manipulate(x))
}

It would be great not to lint here too. But it can always be done later if this proves cumbersome.

[yusufraji]

This test case should be added, to reflect one problem the lint had in its earlier form:

// No lint: maps other than the receiver
fn map_not_arg(arg: Option<u32>) -> Option<u32> {
    maps_static_option().map(|_| arg.unwrap())
}

Also, wrapping a function can be done more explicitly than with just the function name:

// No lint: wrapper function with η-expanded form
fn manipulate_opt_explicit(opt_i: Option<i32>) -> Option<i32> {
    opt_i.map(|x| manipulate(x))
}

It would be great not to lint here too. But it can always be done later if this proves cumbersome.

Thanks, I've added it.

[samueltardieu]

It looks like it lints in the current case (look at the stderr file).

[yusufraji]

Yes, I just noticed that. For future reference, is there a way to change status of the PR to WIP, in case I find a problem I urgently need to resolve.

[samueltardieu]

You have two ways of doing this:

• Use rustbot with "@rustbot author" to indicate that your PR waits for an action on your side, and "@rustbot review" when you want to switch it back to ready to review.
• Using the GitHub interface, you can at any point set the PR to "Draft", then set it back to "Ready" when you're done. This has the disadvantage of not changing the status in the TriageBot dashboard AFAICT.