Suggest Entry::or_default for Entry::or_insert(Default::default())
#9342
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dswij (or someone else) soon. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
☔ The latest upstream changes (presumably #9295) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #8804) made this pull request unmergeable. Please resolve the merge conflicts. |
dswij
added
S-waiting-on-author
|
Thanks again for this! @bors r+ |
Suggest `Entry::or_default` for `Entry::or_insert(Default::default())` Unlike past similar work done in #6228, expand the existing `or_fun_call` lint to detect `or_insert` calls with a `T::new()` or `T::default()` argument, much like currently done for `unwrap_or` calls. In that case, suggest the use of `or_default`, which is more idiomatic. Note that even with this change, `or_insert_with(T::default)` calls aren't detected as candidates for `or_default()`, in the same manner that currently `unwrap_or_else(T::default)` calls aren't detected as candidates for `unwrap_or_default()`. Also, as a nearby cleanup, change `KNOW_TYPES` from `static` to `const`, since as far as I understand it's preferred (should Clippy have a lint for that?). Addresses #3812. *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: [`or_fun_call`]: Suggest `Entry::or_default` for `Entry::or_insert(Default::default())`
|
💔 Test failed - checks-action_dev_test |
|
The test failure is a result of some changes to |
Unlike past similar work done in rust-lang#6228, expand the existing `or_fun_call` lint to detect `or_insert` calls with a `T::new()` or `T::default()` argument, much like currently done for `unwrap_or` calls. In that case, suggest the use of `or_default`, which is more idiomatic. Note that even with this change, `or_insert_with(T::default)` calls aren't detected as candidates for `or_default()`, in the same manner that currently `unwrap_or_else(T::default)` calls aren't detected as candidates for `unwrap_or_default()`. Also, as a nearby cleanup, change `KNOW_TYPES` from `static` to `const`, since as far as I understand it's preferred (should Clippy have a lint for that?). Fixes rust-lang#3812.
Done. |
|
@bors r=dswij |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Was this simply unimplemented, or is there an impediment that I am not seeing? Would I be wasting everyone's time by trying to do this? |
`unwrap_or_else_default` -> `unwrap_or_default` and improve resulting lint Resolves #10080 (though it doesn't implement exactly what's described there) This PR does the following: 1. Merges `unwrap_or_else_default.rs`'s code into `or_fun_call.rs` 2. Extracts the code to handle `unwrap_or(/* default value */)` and similar, and moves it into `unwrap_or_else_default` 3. Implements the missing functionality from #9342, e.g.,, to handle `or_insert_with(Default::default)` 4. Renames `unwrap_or_else_default` to `unwrap_or_default` (since the "new" lint handles both `unwrap_or` and `unwrap_or_else`, it seemed sensible to use the shortened name) This PR is currently two commits. The first implements 1-3, the second implements 4. A word about 2: the `or_fun_call` lint currently produces warnings like the following: ``` error: use of `unwrap_or` followed by a call to `new` --> $DIR/or_fun_call.rs:56:14 | LL | with_new.unwrap_or(Vec::new()); | ^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()` ``` To me, such warnings look like they should come from `unwrap_or_else_default`, not `or_fun_call`, especially since `or_fun_call` is [in the nursery](#9829). --- changelog: Move: Renamed `unwrap_or_else_default` to [`unwrap_or_default`] [#10120](#10120) changelog: Enhancement: [`unwrap_or_default`]: Now handles more functions, like `or_insert_with` [#10120](#10120) <!-- changelog_checked-->
Unlike past similar work done in #6228, expand the existing
or_fun_calllint to detect
or_insertcalls with aT::new()orT::default()argument, much like currently done for
unwrap_orcalls. In that case,suggest the use of
or_default, which is more idiomatic.Note that even with this change,
or_insert_with(T::default)callsaren't detected as candidates for
or_default(), in the same mannerthat currently
unwrap_or_else(T::default)calls aren't detected ascandidates for
unwrap_or_default().Also, as a nearby cleanup, change
KNOW_TYPESfromstatictoconst,since as far as I understand it's preferred (should Clippy have a lint
for that?).
Addresses #3812.
Please write a short comment explaining your change (or "none" for internal only changes)
changelog: [
or_fun_call]: SuggestEntry::or_defaultforEntry::or_insert(Default::default())