-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
odd new_ret_no_self warning: return type that wraps Self #3313
Comments
Found another one in my own code
I consider this a FP. |
Where does clippy look to determine what is considered standard behavior? Does the Rust standard library have any examples of a I'm not trying to express an opinion one way or another here, I'd just like to understand how it is determined whether something like this should be considered a false positive or not? |
|
Mostly the libstd. There's no established process except for judgement calls though. We could walk the return type and if it contains Or if we want to be more strict, we only accept |
This also resulted in many errors in futures on |
…tion. fix trivial typo on the way
new_ret_no_self: add sample from #3313 to Known Problems section.
I've started working on this. |
3338: new_ret_no_self false positives r=flip1995 a=JoshMcguigan ~~WORK IN PROGRESS~~ I plan to fix all of the false positives in #3313 in this PR, but I wanted to open it now to start gathering feedback. In this first commit, I've updated the lint to allow tuple return types as long as `Self` shows up at least once, in any position of the tuple. I believe this is the broadest possible interpretation of what should be allowed for tuple return types, but I would certainly be okay making the lint more strict. fixes #3313 Co-authored-by: Josh Mcguigan <[email protected]>
3338: new_ret_no_self false positives r=flip1995 a=JoshMcguigan ~~WORK IN PROGRESS~~ I plan to fix all of the false positives in #3313 in this PR, but I wanted to open it now to start gathering feedback. In this first commit, I've updated the lint to allow tuple return types as long as `Self` shows up at least once, in any position of the tuple. I believe this is the broadest possible interpretation of what should be allowed for tuple return types, but I would certainly be okay making the lint more strict. fixes #3313 Co-authored-by: Josh Mcguigan <[email protected]>
…lems section." This reverts commit fd2f6dd. Issue rust-lang#3313 has been fixed.
The lint was changed to be more lenient than the documentation implies in PR rust-lang#3338. Related issue rust-lang#3313
Changes: ```` new_ret_no_self: add sample from rust-lang#3313 to Known Problems section. Support multiline comments and hopefully fix panic Check for comments in collapsible ifs Resolve ICE in needless range loop lint RIIR update_lints: Update changelog links Rename if_let_redundant_pattern_matching to redundant_pattern_matching Add lint for redundant pattern matching for explicit return boolean Fix issue rust-lang#3322: reword help message for len_zero Simplify manual_memcpy suggestion in some cases Fix dogfood Update known problems for unnecessary_fold RIIR update_lints: Replace lint count in README.md Rename `active_lints` to `usable_lints` Add comment on WalkDir vs. fs::read_dir sort_by -> sort_by_key Some more documentation for clippy_dev Use `WalkDir` to also gather from subdirectories Avoid linting `boxed_local` on trait implementations. Website: Make lint categories linkable Restore clippy_dummy's placeholder name Swap order of methods in `needless_range_loop` suggestion in some cases Revert "Exclude pattern guards from unnecessary_fold lint" Exclude pattern guards from unnecessary_fold lint ````
clippy @ 601cc9d
This code comes from rls
It causes the following clippy warning:
I tried fixing this by making both
ConcurrentJob
s beSelf
however, ciippy kept warning, probably because it does not understand that the constructor actually returns a tuple ofSelf
and something else?=>
The text was updated successfully, but these errors were encountered: