Skip to content
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 125 commits into from
Oct 9, 2020
Merged

Update Clippy #77747

merged 125 commits into from
Oct 9, 2020

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Oct 9, 2020

Biweekly Clippy update.

This includes a Cargo.lock update: 7ea42be

r? @Manishearth

tnielens and others added 30 commits September 6, 2020 23:06
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.
…, 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
JPTIZ and others added 14 commits October 8, 2020 09:06
…_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
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 9, 2020
@Manishearth
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Oct 9, 2020

📌 Commit 7ea42be has been approved by Manishearth

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 9, 2020
@flip1995
Copy link
Member Author

flip1995 commented Oct 9, 2020

Probably should have rollup=never, because of the Cargo.lock update?

@Manishearth
Copy link
Member

@bors rollup=never

yep

@bors
Copy link
Contributor

bors commented Oct 9, 2020

⌛ Testing commit 7ea42be with merge 7b06cb1...

@bors
Copy link
Contributor

bors commented Oct 9, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: Manishearth
Pushing 7b06cb1 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 9, 2020
@bors bors merged commit 7b06cb1 into rust-lang:master Oct 9, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 9, 2020
@flip1995 flip1995 deleted the clippyup branch October 10, 2020 08:20
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.