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

implicit_return on deny falsely adds return in front of the code block for async closures #14411

Open
FallBackITA27 opened this issue Mar 15, 2025 · 1 comment · May be fixed by #14446
Open
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have

Comments

@FallBackITA27
Copy link

Summary

the implicit_return set on deny adds a return (or multiple) in front the braces for the closure's code block. This doesn't clash well with the fact that rust-fmt automatically puts expressions such as async || return ... into a block like async || { return ... }.

Lint Name

implicit_return

Reproducer

I tried this code:

    return crate::api::v1::basic_get::<Champs>(data, async |x| {
        Champs::filter_by_category(
            Category::try_from(path.into_inner()).unwrap_or(Category::NonSc),
            x,
        )
        .await;
    )
    .await;

I saw this happen:

    return crate::api::v1::basic_get::<Champs>(data, async |x| return return return return return {
        Champs::filter_by_category(
            Category::try_from(path.into_inner()).unwrap_or(Category::NonSc),
            x,
        )
        .await;
    })
    .await;

I expected to see this happen:

    return crate::api::v1::basic_get::<Champs>(data, async |x| {
        return Champs::filter_by_category(
            Category::try_from(path.into_inner()).unwrap_or(Category::NonSc),
            x,
        )
        .await;
    )
    .await;

Version

rustc 1.85.0 (4d91de4e4 2025-02-17)
binary: rustc
commit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688
commit-date: 2025-02-17
host: x86_64-unknown-linux-gnu
release: 1.85.0
LLVM version: 19.1.7

Additional Labels

No response

@FallBackITA27 FallBackITA27 added C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have labels Mar 15, 2025
@FallBackITA27
Copy link
Author

Not quite a minimal example but it gets the point across I believe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: Clippy is not doing the correct thing I-false-positive Issue: The lint was triggered on code it shouldn't have
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant