bors [Wed, 5 May 2021 17:33:46 +0000 (17:33 +0000)]
Auto merge of #7170 - flip1995:revert_drop_order, r=llogiq
Fix stack overflow issue in `redundant_pattern_matching`
Fixes #7169
~~cc `@Jarcho` Since tomorrow is release day and we need to get this also fixed in beta, I'll just revert the PR instead of looking into the root issue. Your changes are good, so if you have an idea what could cause this stack overflow and know how to fix it, please open a PR that reverts this revert with a fix.~~
r? `@llogiq`
changelog: none (fixes stack overflow, but this was introduced in this release cycle)
bors [Wed, 5 May 2021 17:11:14 +0000 (17:11 +0000)]
Auto merge of #6887 - xFrednet:4310-internal-metadata-extraction-lint, r=xFrednet
A metadata collection monster
This PR introduces a metadata collection lint as discussed in #4310. It currently collects:
* The lint ID
* The lint declaration file and location (for #1303)
* The lint group
* The documentation
* The applicability (if resolvable)
* If the suggestion is a multi-part-suggestion
This data has a slightly different structure than the current [lints.json](https://github.com/rust-lang/rust-clippy/blob/gh-pages/master/lints.json) and doesn't include depreciated lints yet. I plan to adapt the website to the new format and include depreciated lints in a follow-up PR :). The current collected json looks like this: [metadata_collection.json](https://gist.github.com/xFrednet/6b9e2c3f725f476ba88db9563f67e119)
The entire implementation is guarded behind the `metadata-collector-lint` feature and the `ENABLE_METADATA_COLLECTION` environment value to prevent default collection. You can test the implementation via:
```sh
$ ENABLE_METADATA_COLLECTION=1 cargo test --test dogfood --all-features
```
changelog: none
---
The size of this PR sadly also grew into a small monster, sorry! I definitely plan to improve on this! And it's totally okay if you take your time with this :)
bors [Mon, 3 May 2021 14:44:44 +0000 (14:44 +0000)]
Auto merge of #7156 - hellow554:single_char_strip, r=flip1995
[single_char_pattern] add strip_prefix and strip_suffix
Title says it all. Adjusted ui tests.
I added the second commit in case you don't like that I moved that table into `single_char_pattern.rs` directly. I don't see any reason why it shouldn't be in that file. It isn't used anywhere else.
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: add strip_prefix and strip_suffix to single_char_pattern lint
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.
projects / rust.git / log