-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Update Clippy #77747
Merged
Merged
Update Clippy #77747
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It emits a lint when the pushed item is a literal, a constant and an immutable binding that are initialized with those.
Add tests in which the variable is initialized with a match expression and function call
Fix a false positive in `explicit_counter_loop` where the loop counter is used after incremented, adjust the test so that counters are incremented at the end of the loop and add the test for this false positive.
This reverts commit 7a66e65.
This reverts commit 5d66bd7.
…, r=matthiaskrgr Fix a FP in `explicit_counter_loop` Fixes rust-lang#4677 and rust-lang#6074 Fix a false positive in `explicit_counter_loop` where the loop counter is used after incremented, adjust the test so that counters are incremented at the end of the loop and add the test for this false positive. --- changelog: Fix a false positive in `explicit_counter_loop` where the loop counter is used after incremented
…thiaskrgr Revert: or_fun_call should lint calls to `const fn`s with no args The changes in rust-lang#5889 and rust-lang#5984 were done under the incorrect assumption that a `const fn` with no args was guaranteed to be evaluated at compile time. A `const fn` is only guaranteed to be evaluated at compile time if it's inside a const context (the initializer of a `const` or a `static`). See this [zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Common.20misconception.3A.20.60const.20fn.60.20and.20its.20effect.20on.20codegen/near/208059113) for more details on this common misconception. Given that none of the linted methods by `or_fun_call` can be called in const contexts, the lint should make no exceptions. changelog: [`or_fun_call`] lints again calls to `const fn` with no args
This lint shouldn't be emitted in `build.rs` as `println!` and `print!` are used for the build script.
… r=lcnr Allow a unique name to be assigned to dataflow graphviz output Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.
Update Clippy Bi-weekly Clippy update. This includes a `Cargo.lock` update (d445493), so probably needs `rollup=never`. r? `@Manishearth`
It does not seem to be necessary
This should improve the performance by avoiding codegen
UI tests cleanup `@matthiaskrgr` noticed some `run-pass` annotations in some crash tests that were added in rust-lang#3922. At that moment they seemed to be necessary to make the tests fail in case of an ICE, but they do not seem to be needed anymore. To test this I forced an ICE in a file with and without annotations, with and without stderr files, and the ICE makes the test fail every time. In addition, I've applied a suggestion from `@ehuss` and `@jyn514` to add `emit=metadata` to the rustc flags for the UI tests. In my machine this improved the run time from ~17 to ~12 seconds. changelog: none
…_merge_policy, r=Manishearth Add note that we follow a rustc no merge-commit policy I think it would be better to add a note that we follow a rustc no merge-commit policy. For example, it was mentioned at rust-lang/rust-clippy#5694 (comment). changelog: none
Downgrade string_lit_as_bytes to nursery Between rust-lang#1402 (regarding `to_owned`) and rust-lang#4494 (regarding `impl Read`), as well as other confusion I've seen hit in my work codebase involving string_lit_as_bytes (`"...".as_bytes().into()`), I don't think this lint is at a quality to be enabled by default. I would consider re-enabling this lint after it is updated to understand when the surrounding type information is sufficient to unsize `b"..."` to &\[u8\] without causing a type error. As currently implemented, this lint is pushing people to write `&b"_"[..]` which is not an improvement over `"_".as_bytes()` as far as I am concerned. --- changelog: Remove string_lit_as_bytes from default set of enabled lints
clippy_lints: Do not warn against Box parameter in C FFI changelog: [`boxed_local`]: don't lint in `extern fn` arguments Fixes rust-lang#5542. When using C FFI, to handle pointers in parameters it is needed to declare them as `Box` in its Rust-side signature. However, the current linter warns against the usage of Box stating that "local variable doesn't need to be boxed here". This commit fixes it by ignoring functions whose Abi is C.
Backport remerge Step 1 in the release process. r? `@ghost` changelog: none
Add changelog for 1.48 beta [Rendered](https://github.com/ebroto/rust-clippy/blob/changelog_1_48/CHANGELOG.md) I've not added the PRs fixing `same_item_push` because those were backported, namely: * [rust-lang#5908](rust-lang/rust-clippy#5908) * [rust-lang#5997](rust-lang/rust-clippy#5997) * [rust-lang#6016](rust-lang/rust-clippy#6016) The following PR was reverted, so I've ignored it too: * [rust-lang#5984](rust-lang/rust-clippy#5984) ~~Also, I took the liberty of adding a "Thanks" section, naming all the contributors to this release. I think they deserve visibility in the changelog. Please tell me if we want to add this or maybe it's redundant given we link to the PRs?~~ changelog: none r? `@flip1995`
Clippy dev subcommand to build and serve website This PR adds `clippy dev serve` which will pop open a browser with a local rendered 'ALL the Clippy Lints' website, and re-render as you edit stuff. --- changelog: none
@bors r+ |
📌 Commit 7ea42be has been approved by |
Probably should have |
@bors rollup=never yep |
☀️ Test successful - checks-actions, checks-azure |
This was referenced Oct 9, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
merged-by-bors
This PR was explicitly merged by bors.
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Biweekly Clippy update.
This includes a
Cargo.lock
update: 7ea42ber? @Manishearth