bors [Sun, 2 May 2021 14:00:09 +0000 (14:00 +0000)]
Auto merge of #7150 - camsteffen:better-conf, r=llogiq
`Conf` macro improvements
changelog: Allow `default_trait_access` in macros
Mainly this is a change to use serde as in [Manually implementing Deserialize for a struct](https://serde.rs/deserialize-struct.html), which opens the door for a cleaner implementation overall.
* Allow `default_trait_access` in macros (tangential, but used in this PR)
* Deserialize into `TryConf { conf, errors }` instead of using a global `ERRORS` variable.
* Improve the `define_Conf!` macro
* Remove the redundant string literal `(name, "name", ..)`
* Support deprecated configs with `#[conf_deprecated(message)]`. Message shows in error.
* Make the default value optional. Use `Default::default()` if omitted.
* Invalid config value error now shows the key (see test output)
* Cleaner `impl Default for Conf` (no `toml::from_str("")`)
Auto merge of #6951 - Jarcho:implicit_return_fp, r=flip1995
`implicit_return` improvements
fixes: #6940
changelog: Fix `implicit_return` suggestion for async functions
changelog: Improve `implicit_return` suggestions when returning the result of a macro
changelog: Check for `break` expressions inside a loop which are then implicitly returned
changelog: Allow all diverging functions in `implicit_return`, not just panic functions
Auto merge of #7140 - matthiaskrgr:ice_std, r=llogiq
fix ice when checking rustc libstd
```
thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', src/tools/clippy/clippy_lints/src/matches.rs:1595:53
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
I don't have a minimised testcase because I don't have time to reduce libstd down to a few lines right now.
---
changelog: fix index out of bounds access when checking rustc libstd
thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', src/tools/clippy/clippy_lints/src/matches.rs:1595:53
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I don't have a minimised testcase because I don't have time to reduce libstd down to a few lines right now.
Auto merge of #7138 - mgacek8:issue6808_iter_cloned_collect_FN_with_large_array, r=Manishearth
Fix FN in `iter_cloned_collect` with a large array
fixes #6808
changelog: Fix FN in `iter_cloned_collect` with a large array
I spotted that [is_iterable_array](https://github.com/rust-lang/rust-clippy/blob/a362a4d1d0edb66aef186c1d27b28c60573078f4/clippy_lints/src/loops/explicit_iter_loop.rs#L67-L75) function that `explicit_iter_loop` lint is using only works for array sizes <= 32.
There is this comment:
> IntoIterator is currently only implemented for array sizes <= 32 in rustc
I'm a bit confused, because I read that [IntoIterator for arrays](https://doc.rust-lang.org/src/core/array/mod.rs.html#194-201) with const generic `N` is stable since = "1.0.0". Although Const Generics MVP were stabilized in Rust 1.51.
Should I set MSRV for the current change? I will try to test with older compilers soon.
Auto merge of #7137 - camsteffen:msrv-mod, r=llogiq
Refactor MSRV aliases
changelog: Remove MSRV from `needless_question_mark` and change MSRV for `missing_const_for_fn` from 1.37.0 to 1.46.0.
First [mentioned on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Better.20MSRV.20testing.20idea/near/236215074).
* Moves MSRV constants into `clippy_utils::msrvs`. Now they are named to represent a stabilized feature flag or library item that is required for a lint's suggestion.
* `needless_question_mark` no longer has MSRV. Not needed since it does not suggest adding `?`.
* `missing_const_for_fn` MSRV was changed from 1.37.0 to 1.46.0. This seems to be a past mistake.
Auto merge of #7132 - rust-lang:single_element_loop_iter, r=Manishearth
extend `single_element_loop` to match `.iter()`
This extends `single_element_loop` to also match `[..].iter()` in the loop argument. Related to #7125, but not completely fixing it due to the lint only firing if the array expression contains a local variable.
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
projects / rust.git / log