Skip to content

Conversation

yusufraji
Copy link
Contributor

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
Copy link
Collaborator

rustbot commented Jan 19, 2025

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

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jan 19, 2025
@yusufraji
Copy link
Contributor Author

r? @llogiq

@rustbot rustbot assigned llogiq and unassigned Manishearth Jan 19, 2025
@samueltardieu
Copy link
Member

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)
}

@yusufraji yusufraji force-pushed the single_option_map branch 2 times, most recently from dc114ee to a2283e0 Compare January 28, 2025 07:18
Copy link
Member

@samueltardieu samueltardieu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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.

Copy link
Contributor

@llogiq llogiq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we may want to look into the the closure and not lint when it's anything but a function call.

This also applies to function arguments, which should be paths to lint. We shouldn't lint arg1.map(|a1| f(a1, arg2 + 1)). Edit: I'm confused, we should certainly lint that.

@llogiq llogiq enabled auto-merge February 9, 2025 21:53
@llogiq llogiq added this pull request to the merge queue Feb 9, 2025
Merged via the queue into rust-lang:master with commit c3239ba Feb 9, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

lint functions that map over option arg

5 participants