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

Pull changes from rust-lang/rust-clippy #72972

Merged
merged 111 commits into from
Jun 10, 2020
Merged

Pull changes from rust-lang/rust-clippy #72972

merged 111 commits into from
Jun 10, 2020

Conversation

tesuji
Copy link
Contributor

@tesuji tesuji commented Jun 4, 2020

No description provided.

Mark-Simulacrum and others added 30 commits May 10, 2020 22:15
This takes an absolute path to a rustc repo and adds path-dependencies
that point towards the respective rustc subcrates into the Cargo.tomls of
the clippy and clippy_lints crate.

This allows rustc-analyzer to show proper type annotations etc on rustc-internals inside the clippy repo.

Usage: cargo dev ra-setup /absolute/path/to/rust/

cc rust-lang/rust-analyzer#3517
cc rust-lang/rust-clippy#5514
Stabilize str_strip feature

This PR stabilizes these APIs:

```rust
impl str {
    /// Returns a string slice with the prefix removed.
    ///
    /// If the string starts with the pattern `prefix`, `Some` is returned with the substring where
    /// the prefix is removed. Unlike `trim_start_matches`, this method removes the prefix exactly
    /// once.
    pub fn strip_prefix<'a, P: Pattern<'a>>(&'a self, prefix: P) -> Option<&'a str>;

    /// Returns a string slice with the suffix removed.
    ///
    /// If the string ends with the pattern `suffix`, `Some` is returned with the substring where
    /// the suffix is removed. Unlike `trim_end_matches`, this method removes the suffix exactly
    /// once.
    pub fn strip_suffix<'a, P>(&'a self, suffix: P) -> Option<&'a str>
    where
        P: Pattern<'a>,
        <P as Pattern<'a>>::Searcher: ReverseSearcher<'a>;
}
```

Closes  rust-lang#67302
Update Clippy, RLS, and rustfmt

r? @Dylan-DPC

This makes Clippy test-pass again: 3089c3b

Otherwise this includes bugfixes and a few new lints.

Fixes rust-lang#72231
Fixes rust-lang#72232
Rustup

r? @matthiaskrgr

I finally got to doing the rustup. Sorry for taking so long, I was busy the last few days.

@ebroto FYI: I had to add b6c58f0 to make Clippy pass the rustc test suite.

changelog: none
cargo_dev: add ra-setup

It takes an absolute path to a rustc repo and adds path-dependencies
that point towards the respective rustc subcrates into the Cargo.tomls of
the clippy and clippy_lints crate.

This allows rustc-analyzer to show proper type annotations etc on rustc-internals inside the clippy repo.

Usage: cargo dev ra-setup /absolute/path/to/rust/

cc rust-lang/rust-analyzer#3517
cc rust-lang/rust-clippy#5514

changelog: none
… r=yaahc,flip1995

new lint: vec_resize_to_zero

implements rust-lang#5444

changelog: new lint vec_resize_to_zero
len_zero: skip ranges if feature `range_is_empty` is not enabled

If the feature is not enabled, calling `is_empty()` on a range is ambiguous. Moreover, the two possible resolutions are unstable methods, one inherent to the range and the other being part of the `ExactSizeIterator` trait.

Since `len_zero` only checks for existing `is_empty()` inherent methods, we only take into account the `range_is_empty` feature.

Related: rust-lang#48111 (comment)

changelog: len_zero: avoid linting ranges without #![feature(range_is_empty)]

Fixes: rust-lang#3807
…shearth

add testcase that no longer ICEs

Fixes rust-lang#3969

changelog: none
Rollup of 3 pull requests

Successful merges:

 - rust-lang#5637 (new lint: vec_resize_to_zero)
 - rust-lang#5656 (len_zero: skip ranges if feature `range_is_empty` is not enabled)
 - rust-lang#5663 (add testcase that no longer ICEs)

Failed merges:

r? @ghost

changelog: rollup
moved cast_ptr_alignment to pedantic and expanded documentation

fixes: rust-lang#5618
changelog: cast_ptr_alignment moved to pedantic
`clippy_lints` makes use of `dep_kinds` on `NodeDep` but this was only
added in versoin 0.9.1. Compiling with 0.9.0 will fail because of this.
multipart suggestions aren't autofixable by rustfix yet
@tesuji
Copy link
Contributor Author

tesuji commented Jun 8, 2020

I reset to latest master and did subtree pull again.

bors and others added 4 commits June 8, 2020 13:49
…hansch

New lint: `unnested_or_patterns`

changelog: Adds a lint `unnested_or_patterns`, suggesting `Some(0 | 2)` as opposed to `Some(0) | Some(2)`. The lint only fires on compilers capable of using `#![feature(or_patterns)]`.

- The lint is primarily encoded as a pure algorithm which to unnest or-patterns in an `ast::Pat` (`fn unnest_or_patterns`) through a `MutVisitor`. After that is done, and assuming that any change was detected, then `pprust::pat_to_string` is used to simply convert the transformed pattern into a suggestion.

- The PR introduces a module `utils::ast_utils` with a bunch of functions for spanless & nodeless equality comparisons of ASTs.

cc rust-lang#54883
let_and_return: avoid "does not live long enough" errors

EDIT: Add rust-lang#3324 to the list of fixes

<details>
<summary>Description of old impl</summary>
<br>
Avoid suggesting turning the RHS expression of the last statement into the block tail expression if a temporary borrows from a local that would be destroyed before.

This is my first incursion into MIR so there's probably room for improvement!
</details>

Avoid linting if the return type of some method or function called in the last statement has a lifetime parameter.

changelog: Fix false positive in [`let_and_return`]

Fixes rust-lang#3792
Fixes rust-lang#3324
reversed_empty_ranges: avoid linting N..N except in for loop arguments

changelog: [`reversed_empty_ranges`]: avoid linting N..N except in for loop arguments

r? @yaahc
Fixes rust-lang#5689
@tesuji
Copy link
Contributor Author

tesuji commented Jun 9, 2020

Rebased. Could you raise the build queue priority, @Manishearth ?

@tesuji
Copy link
Contributor Author

tesuji commented Jun 9, 2020

@flip1995 Is the "merge commit" necessary to subtree pull to work properly?
IIRC the rust repo discourages the "merge commits".

@flip1995
Copy link
Member

flip1995 commented Jun 9, 2020

The merge commit is generated by subtree pull. We use it to easily find the clippy commit on releases. So I would say, it is necessary.

@Manishearth
Copy link
Member

@bors p=4

@tesuji
Copy link
Contributor Author

tesuji commented Jun 9, 2020

Thank you but you might also want to reapprove this PR

@Manishearth
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jun 9, 2020

📌 Commit 41c845e has been approved by Manishearth

@Mark-Simulacrum
Copy link
Member

(FWIW if there's a general need for prioritization of clippy ups despite the move to subtree, that's surprising to me and we should discuss it at some point. One of the goals with moving away from submodules is avoiding the need to prioritize PRs like this; if that's not being met that may be acceptable but we should discuss).

@Manishearth
Copy link
Member

@Mark-Simulacrum I mean, yes, these PRs need to be prioritized, but only because we make them much less often.

In the old world the PRs needed to be made every week and had to be prioritized to fix clippy. Now they need to be prioritized because:

  • It's easier to deal with git history when you make a sync PR with no extra commits sneaking in
  • It's easier to avoid merge conflicts

The prioritization is for a different reason, and since syncs are much more rare it shouldn't matter as much.

@bors
Copy link
Contributor

bors commented Jun 9, 2020

⌛ Testing commit 41c845e with merge 2835224...

@bors
Copy link
Contributor

bors commented Jun 10, 2020

☀️ Test successful - checks-azure
Approved by: Manishearth
Pushing 2835224 to master...

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.