Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add single_option_map lint #14033

Merged
merged 1 commit into from
Feb 9, 2025
Merged

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
Contributor

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
Contributor

@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