Jason Newcomb [Fri, 2 Apr 2021 02:46:10 +0000 (22:46 -0400)]
Improve `implicit_return`
Better suggestions when returning macro calls.
Suggest changeing all the break expressions in a loop, not just the final statement.
Don't lint divergent functions.
Don't suggest returning the result of any divergent fuction.
Auto merge of #78880 - CDirkx:not_supported, r=joshtriplett
Add `Unsupported` to `std::io::ErrorKind`
I noticed a significant portion of the uses of `ErrorKind::Other` in std is for unsupported operations.
The notion that a specific operation is not available on a target (and will thus never succeed) seems semantically distinct enough from just "an unspecified error occurred", which is why I am proposing to add the variant `Unsupported` to `std::io::ErrorKind`.
**Implementation**:
The following variant will be added to `std::io::ErrorKind`:
```rust
/// This operation is unsupported on this platform.
Unsupported
```
`std::io::ErrorKind::Unsupported` is an error returned when a given operation is not supported on a platform, and will thus never succeed; there is no way for the software to recover. It will be used instead of `Other` where appropriate, e.g. on wasm for file and network operations.
`decode_error_kind` will be updated to decode operating system errors to `Unsupported`:
- Unix and VxWorks: `libc::ENOSYS`
- Windows: `c::ERROR_CALL_NOT_IMPLEMENTED`
- WASI: `wasi::ERRNO_NOSYS`
**Stability**:
This changes the kind of error returned by some functions on some platforms, which I think is not covered by the stability guarantees of the std? User code could depend on this behavior, expecting `ErrorKind::Other`, however the docs already mention:
> Errors that are `Other` now may move to a different or a new `ErrorKind` variant in the future. It is not recommended to match an error against `Other` and to expect any additional characteristics, e.g., a specific `Error::raw_os_error` return value.
The most recent variant added to `ErrorKind` was `UnexpectedEof` in `1.6.0` (almost 5 years ago), but `ErrorKind` is marked as `#[non_exhaustive]` and the docs warn about exhaustively matching on it, so adding a new variant per se should not be a breaking change.
The variant `Unsupported` itself could be marked as `#[unstable]`, however, because this PR also immediately uses this new variant and changes the errors returned by functions I'm inclined to agree with the others in this thread that the variant should be insta-stabilized.
Auto merge of #7075 - xFrednet:7054-fp-branches-sharing-code, r=camsteffen,flip1995
Fixing FPs for the `branches_sharing_code` lint
Fixes #7053
Fixes #7054
And an additional CSS adjustment to support dark mode for every inline code. It currently only works in paragraphs, which was an oversight on my part :sweat_smile:. [Current Example](https://rust-lang.github.io/rust-clippy/master/index.html#blacklisted_name)
This also includes ~50 lines of doc comments and is therefor not as big as the changes would indicate. :penguin:
---
changelog: none
All of these bugs were introduced in this dev version and are therefor not worth a change log entry.
r? `@phansch`
cc: `@camsteffen` since you have a pretty good overview of the `SpanlessEq` implementation :upside_down_face:
Auto merge of #6568 - Jarcho:redundant_pattern_matching, r=flip1995
Fix: redundant_pattern_matching drop order
Fixes #5746
A note about the change in drop order is added when the scrutinee (or any temporary in the expression) isn't known to be safe to drop in any order (i.e. doesn't implement the `Drop` trait, or contain such a type). There is a whitelist for some `std` types, but it's incomplete. Currently just `Vec<_>`, `Box<_>`, `Rc<_>` and `Arc<_>`, but only if the contained type is also safe to drop in any order.
Another lint for when the drop order changes could be added as allowed by default, but the drop order requirement is pretty subtle in this case. I think the note added to the lint should be enough to make someone think before applying the change.
changelog: Added a note to `redundant_pattern_matching` when the change in drop order might matter
Still need to handle the value returned by `insert` correctly.
changelog: Improve `map_entry` suggestion. Will now suggest `or_insert`, `insert_with` or `match _.entry(_)` as appopriate.
changelog: Fix `map_entry` false positives where the entry api can't be used. e.g. when the map is used for multiple things.
Auto merge of #7085 - Jarcho:manual_map_autoderef, r=giraffate
Don't allow adjustments for `manual_map`
fixes: #7077
The other option here would be to add the return type to the closure. It would be fine for simple types, but longer types can be rather unwieldy. Could also implement the adjustment manually.
changelog: Don't lint `manual_map` when type adjustments are added. e.g. autoderef
Jason Newcomb [Fri, 2 Apr 2021 23:04:45 +0000 (19:04 -0400)]
`redundant_pattern_matching` fix inverted boolean when missing `Drop` trait\r\r# Please enter the commit message for your changes. Lines starting\r# with '#' will be ignored, and an empty message aborts the commit.\r#\r# Date: Fri Apr 2 19:04:45 2021 -0400\r#\r# On branch redundant_pattern_matching\r# Your branch is ahead of 'origin/redundant_pattern_matching' by 1 commit.\r# (use "git push" to publish your local commits)\r#\r# Changes to be committed:\r# modified: clippy_lints/src/matches.rs\r#\r\r# Please enter the commit message for your changes. Lines starting\r# with '#' will be ignored, and an empty message aborts the commit.\r#\r# Date: Fri Apr 2 19:04:45 2021 -0400\r#\r# interactive rebase in progress; onto ebc64690d\r# Last commands done (6 commands done):\r# pick 25d211ad8 Code cleanup and additional std types checked\r# r 0c71ce56f `redundant_pattern_matching` fix inverted boolean when missing `Drop` trait\r# No commands remaining.\r# You are currently editing a commit while rebasing branch 'redundant_pattern_matching' on 'ebc64690d'.\r#\r# Changes to be committed:\r# modified: clippy_lints/src/matches.rs\r#
Auto merge of #7049 - Jarcho:remove_match_path, r=camsteffen
Remove `match_path` and `match_qpath`
The only remaining usage is the `author` lint, so the functions are left in for now. The test result for `repl_uninit` changed, the lint was broken before.
The `collapsible_span_lint_calls` and `match_type_on_diag_item` tests have been changed. Both lints were broken when utils was extracted into it's own crate. `match_type_on_diag_item` isn't quite fixed, but it's at least less broken.
Jason Newcomb [Wed, 7 Apr 2021 20:19:25 +0000 (16:19 -0400)]
Remove all usages of `match_path`, `match_qpath` and `match_path_ast` except the `author` lint.
Add note to fix `MATCH_TYPE_ON_DIAG_ITEM`
Add false negative test for `uninit_assumed_init`
Jason Newcomb [Thu, 25 Mar 2021 13:25:04 +0000 (09:25 -0400)]
Improve `map_entry` lint
Fix false positives where the map is used before inserting into the map.
Fix false positives where two insertions happen.
Suggest using `if let Entry::Vacant(e) = _.entry(_)` when `or_insert` might be a semantic change
Auto merge of #7039 - phansch:melt-ice, r=flip1995
tabs_in_doc_comments: Fix ICE due to char indexing
This is a quick-fix for an ICE in `tabs_in_doc_comments`. The problem
was that we we're indexing into possibly multi-byte characters, such as '位'.
More specifically `get_chunks_of_tabs` was returning indices into
multi-byte characters. Those were passed on to a `Span` creation that
then caused the ICE.
This fix makes sure that we don't return indices that point inside a
multi-byte character. *However*, we are still iterating over unicode
codepoints, not grapheme clusters. So a seemingly single character like y̆ ,
which actually consists of two codepoints, will probably still cause
incorrect spans in the output. But I don't think we handle those cases
anywhere in Clippy currently?
Auto merge of #7076 - rail-rain:missing_const_for_fn, r=phansch
Fix a FP in `missing_const_for_fn`
where a function that calls a standard library function whose constness
is unstable is considered as being able to be a const function. Fixes #5995.
The core change is the move from `rustc_mir::const_eval::is_min_const_fn` to `rustc_mir::const_eval::is_const_fn`. I'm not clear about the difference in their purpose between them so I'm not sure if it's acceptable to call `qualify_min_const_fn::is_min_const_fn` this way now.
---
changelog: `missing_const_for_fn`: No longer lints when an unstably const function is called
Auto merge of #7074 - camsteffen:diag-methods, r=llogiq
Split `is_diagnostic_assoc_item`
changelog: none
* Split `is_diagnostic_assoc_item` into `is_diag_item_method` and `is_diag_trait_item`
* `is_diag_item_method` is a bit more nuanced with the `tcx.type_of(impl_id).ty_adt_def()` step, so it seems better to keep that separate.
* No need to generalize over traits and Adt's since we know which one we want at compile time
* "item" vs. "method" because a trait may have associated items.
* Replaces the usage of the `sym::slice` diagnostic item with the `slice_alloc` lang item. The diagnostic item should be removed from rustc because it is on the `slice_alloc` impl, not slice itself (and it's not needed).
Auto merge of #7064 - ThibsG:WrongSelfFix, r=giraffate
Fix FP in `wrong_self_convention` lint
Previously, this lint didn't check into impl block when it was implementing a trait.
Recent improvements (#6924) have moved this check and some impl blocks are now checked but they shouldn't, such as in #7032.
Fixes #7032
changelog: Fix FP when not taking `self` in impl block for `wrong_self_convention` lint
Auto merge of #7065 - rail-rain:warn_copy_pass_by_ref, r=Manishearth
Add a note on the issue #5953
Hello,
I thought it would be better to have a note and warning about this issue considering it introduced an UB in the past even with the "Search on Github" feature.
---
changelog: Add a note on the issue #5953 to the known problems section.
Auto merge of #7060 - daxpedda:debug-assert-panic-in-result-fn, r=flip1995
Remove `debug_assert` from `panic_in_result_fn`
I couldn't find any documentation on `debug_assert` that should be remove.
In my humble opinion, I would also like to argue that `todo` and `unreachable` shouldn't trigger this lint?
projects / rust.git / log