Rollup of 16 pull requests #82517

The default value for a field type does not necessarily match the default value for that field in the struct Default.

There is already an assertion that consecutive lines assign to a struct field.

[beta] Backport of rust-lang#6375 - field_reassign_with_default fix With the pinned nightly we can test backports to our beta branch now 🎉 cc rust-lang#6515 changelog: beta 1.50: Backport of private fields fix in [`field_reassign_with_default`] lints

This rewrite gets rid of complicated visitors, by using the lint infrastructure as much as possible

Backport remerge changelog: none r? `@ghost`

Update changelog for 1.51 ~~Don't merge yet. This is the last step of the release process.~~ Release process for 1.50 is done, this can now be merged. [Rendered](https://github.com/flip1995/rust-clippy/blob/changelog/CHANGELOG.md) changelog: none

Rework use_self impl based on ty::Ty comparison rust-lang#3410 | Take 2 This builds on top of rust-lang#5531 I already reviewed and approved the commits by `@montrivo.` So only the review of my commits should be necessary. I would also appreciate your review `@montrivo,` since you are familiar with the challenges here. Fixes rust-lang#3410 and Fixes rust-lang#4143 (same problem) Fixes rust-lang#2843 Fixes rust-lang#3859 Fixes rust-lang#4734 and fixes rust-lang#6221 Fixes rust-lang#4305 Fixes rust-lang#5078 (even at expression level now 🎉) Fixes rust-lang#3881 and Fixes rust-lang#4887 (same problem) Fixes rust-lang#3909 Not yet: rust-lang#4140 (test added) All the credit for the fixes goes to `@montrivo.` I only refactored and copy and pasted his code. changelog: rewrite [`use_self`] lint and fix multiple (8) FPs. One to go.

Fix missing_panics_doc warning on `unreachable!`. Fixes rust-lang#6699. Are there any other test-cases I should cover? changelog: [`missing_panics_doc`](https://rust-lang.github.io/rust-clippy/master/index.html#missing_panics_doc): No longer lints on [`unreachable!`](https://doc.rust-lang.org/std/macro.unreachable.html)

…ocation (has precedence over --crates-toml flag)

For context: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Label.20cleanup/near/224083870

…e-files, r=flip1995 Update labels in template files It seems like we forgot to update the GitHub templates when we decided to update the label names. This PR just adjusts the templates to use the new label names :) Context: [Zulip discussion about renaming the labels](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Label.20cleanup/near/224083870) --- changelog: none

lintcheck: accept env var to set crates.toml file *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: lintcheck: accept LINTCHECK_TOML env var to set list of crates to be checked.

…lip1995 Add a minimal reproducer for the ICE in rust-lang#6179 This PR is an auxiliary PR for rust-lang#6179, just add a minimal reproducer for the ICE discussed in rust-lang#6179. See rust-lang#6179 for more details. changelog: none

directly expose copy and copy_nonoverlapping intrinsics This effectively un-does rust-lang#57997. That should help with `ptr::read` codegen in debug builds (and any other of these low-level functions that bottoms out at `copy`/`copy_nonoverlapping`), where the wrapper function will not get inlined. See the discussion in rust-lang#80290 and rust-lang#81163. Cc `@bjorn3` `@therealprof`

Change suggestion logic to filter and checking _before_ creating specific resolution suggestion. Assert earlier that suggestions contain code substitions to make it easier in the future to debug invalid uses. If we find this becomes too noisy in the wild, we can always make the emitter resilient to these cases and remove the assertions. Fix rust-lang#78651.

Fix vec_init_then_push false positives changelog: Fix vec_init_then_push false positives Fixes rust-lang#6615

Fix collapsible_if with attributes changelog: Fix collapsible_if FP with attributes Fixes rust-lang#6593

…1995 Do not lint when the closure is called using an iterator Fix FP when the closure is used in an iterator for `blocks_in_if_conditions` lint FIxes: rust-lang#1141 changelog: none

Items are guaranteed to be HIR owner.

These updates allow us to specify multiple testnames for `TESTNAME`. The new version of compiletest-rs also includes `bless` support, but is not enabled with this PR.

…earth Upgrade compiletest-rs to 0.6 and tester to 0.9 These updates allow us to specify multiple testnames for `TESTNAME` by providing a comma separated list of testnames. The new version of compiletest-rs also includes `bless` support, but is not enabled with this PR. cc rust-lang#5394 changelog: none

…d to execute "git checkout xy" inside the repo dir!

…r contain absolute paths to rustc source files The latter is especially annoying because the paths would change every time we bumped the pinned nightly version.

more lintcheck updates * do some refactoring and renaming here and there * add comments to functions * fix bug where git repos would not get checked out to the proper commits (cmd was not actually run in repo directory 😅 ) * print warnings if we can't clone or check out a git repo * filter out noise from cargo-metadata errors and lint messages that contained absolute file paths (these would change with every pinned-nightly bump, polluting the logs) changelog: more lintcheck refactoring and fixes for git crates

…1995 New lint: default_numeric_fallback fixes rust-lang#6064 r? `@flip1995` As we discussed in [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20.236064/near/224647188) and [here](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Issue.20clippy.236064/near/224746333), I start implementing this lint from the strictest version. In this PR, I'll allow the below two cases to pass the lint to reduce FPs. 1. Appearances of unsuffixed numeric literals in `Local` if `Local` has a type annotation, for example: ```rust // Good. let x: i32 = 1; // Also good. let x: (i32, i32) = if cond { (1, 2) } else { (2, 3) }; ``` 2. Appearances of unsuffixed numeric literals in args of `Call` or `MethodCall` if corresponding arguments of their signature have concrete types, for example: ```rust fn foo_mono(x: i32) -> i32 { x } fn foo_poly<T>(t: T) -> t { t } // Good. let x = foo_mono(13); // Still bad. let x: i32 = foo_poly(13); ``` changelog: Added restriction lint: `default_numeric_fallback`

Test workspace at once changelog: none Follow-up to rust-lang#6733

There is no need to create vec's here

…krgr Lintcheck and an options for command line options Make it possible to add command line options to the clippy invocation of the lintcheck-tool changelog: none r? `@matthiaskrgr` I found that this will be really helpful if we use a separate repository and want to maintain a all-lints-passing list of crates. See my early experimentation here: https://github.com/flip1995/clippy-lintcheck ``` git submodule update --init cargo run -- --mode=all ``` Will run the lintcheck tool on all the specified crates in `config/` in that repository.

Update Clippy Biweekly Clippy update r? `@Manishearth`

Also remove `ast::Mod` which is mostly redundant now

…=varkor Replace if-let and while-let with `if let` and `while let` This pull request replaces if-let and while-let with `if let` and `while let`. closes rust-lang#82205

Fix FP of result_unit_err when using type aliases fixes rust-lang#6546 changelog: none

Fix lintcheck by excluding checked crates from workspace r? `@matthiaskrgr` cc `@camsteffen` So `exclude` doesn't work with glob patterns, but it turns out that it works with `starts_with`. changelog: none

…msteffen Fix for issue 6640 *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: unnecessary_wraps will now suggest to remove unnecessary wrapped return unit type, like Option<()> fixes rust-lang#6640

Use rayon to figure out the threadcount and half that for core count. For each core, create a target dir that is used. Otherwise, when running multiple clippys with the same target-dir, cargo would lock the dir and prevent parallelism. This way we can run multiple clippys at the same time (on root crates) but we sacrifice cache-hits (when we already cargo-checked crate-deps).

ast: Keep expansion status for out-of-line module items I.e. whether a module `mod foo;` is already loaded from a file or not. This is a pre-requisite to correctly treating inner attributes on such modules (rust-lang#81661). With this change AST structures for `mod` items diverge even more for AST structure for the crate root, which previously used `ast::Mod`. Therefore this PR removes `ast::Mod` from `ast::Crate` in the first commit, these two things are sufficiently different from each other, at least at syntactic level. Customization points for visiting a "`mod` item or crate root" were also removed from AST visitors (`fn visit_mod`). `ast::Mod` itself was refactored away in the second commit in favor of `ItemKind::Mod(Unsafe, ModKind)`.

(see https://rustc-dev-guide.rust-lang.org/diagnostics.html for details)

…r lintcheck

defaults to 1 -j 0 choses the number of threads automtically (= number of physical cores)

…p1995 lintcheck: parallelize By default we use a single thread and one target dir as before. If `-j n` is passed, use `n` target dirs and run one clippy in each of them. We need several target dirs because cargo would lock them for a single process otherwise which would prevent the parallelism. `-j 0` makes rayon use $thread_count/2 (which I assume is the number of physical cores of a machine) for the number of threads. Other change: Show output of clippy being compiled when building it for lintcheck (makes it easier to spot compiler errors etc) Show some progress indication in the "Linting... foo 1.2.3" message. Sort crates before linting (previously crates would be split randomly between target dirs, with the sorting, we try to make sure that even crates land in target dir 0 and odd ones in target dir 1 etc..) *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: parallelize lintcheck with rayon

collapsible_match: fix lint message capitalization (see https://rustc-dev-guide.rust-lang.org/diagnostics.html for details) --- *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: collapsible_match: fix lint message capitalization

This is in preparation to upgrade to 8.0.1, so the next commit can contain more meaningful diffs.

From https://github.com/necolas/normalize.css/releases/tag/8.0.1.

This bypasses tidy's complaints about tab indent. Also, this lets us remove comments while keeping the MIT license comment.

Add the from_str_radix_10 lint changelog: added the new `from_str_radix_10` which sometimes replaces calls to `primitive::from_str_radix` to `str::parse` This is ready to be merged, although maybe the category should be `pedantic` instead of `style`? I'm not sure where it fits better. Closes rust-lang#6713.

Teach SpanlessEq binding IDs changelog: Fix collapsible_match false positive Fixes rust-lang#6740 This PR changes the way `SpanlessEq` determines whether two local variables are the same. Instead of checking that the names match, it checks that the `HirId`s match. If local bindings are declared within the expressions that are being compared, `SpanlessEq` will remember bindings that correspond to each other in a `FxHashMap<HirId, HirId>`. This makes `SpanlessEq` more flexible while also fixing false positives. Example: `{ let x = 1; x + 2 }` is equal to `{ let y = 1; y + 2 }`. CC `@xFrednet` I think this will resolve some concerns in rust-lang#6463

… r=flip1995 Change unnecessary_wraps to pedantic changelog: Change unnecessary_wraps to pedantic There seems to be enough evidence that this lint is not wanted as warn-by-default. Attempted before at rust-lang#6380. False positives at rust-lang#6721 and rust-lang#6427. Actually requested to change the category at rust-lang#6726. Closes rust-lang#6726

Fix camel case postfix for `enum_variant_names` lint Fix camel case postfix Fixes: rust-lang#4639 changelog: none

Fix FP in inherent_to_string when the function has generic parameters Minimal example of the false positive: ```` struct G; impl G { fn to_string<const _N: usize>(&self) -> String { "G.to_string()".to_string() } } fn main() { let g = G; g.to_string::<1>(); } ```` Clippy emits an `inherent_to_string` warning, and suggests that we implement `Display` for `G` instead. However, this is not possible, since the generic parameter _N only exists in this function, not in `G` itself. This particular example uses const generics, which is where the issue is most likely to come up, but this PR skips the lint if the `to_string` function has any kind of generic parameters. changelog: Fix FP in `inherent_to_string`

…ed instance

… r=matthiaskrgr Inconsistent struct constructor fixes: rust-lang#6352 r? `@matthiaskrgr` I added the lint that checks for the struct constructors where the order of the field init shorthands is inconsistent with that in the struct definition. changelog: Add style lint: `inconsistent_struct_constructor`

The lint does point out inconsistency with the Rust naming convention, but the fact that rustc does not warn about the inconsistency by default means that clippy probably should not warn by default either. changelog: move upper_case_acronyms lint from style to pedantic group.

…ip1995 upper_case_acronyms: move lint from style to pedantic lint group The lint does point out inconsistency with the Rust naming convention, but the fact that rustc does not warn about the inconsistency by default means that clippy probably should not warn by default either. changelog: move upper_case_acronyms lint from style to pedantic group.

Quick fix cargo dev bless fixes rust-lang#6757 r? `@phansch` Trying to do a quick fix of `bless`, I'm not sure how much work it will need to do transition to `bless` built in `compiletest`, so please feel free to close this PR if it will not need so much. changelog: none

…from_doc, r=phansch Remove unneeded blank lines from doc Remove unneeded blank lines like below. <img width="1142" alt="スクリーンショット 2021-02-22 23 01 17" src="https://user-images.githubusercontent.com/17407489/108719295-bb9ff800-7562-11eb-9338-8f2571e61c56.png"> changelog: none

Automatically clean lintchecks shared target dir (will force clippy to recheck sources) if the clippy binaries are older than the lintcheck logs. Also update lintcheck logs

This improves help messages in two cases: - When expected type is `T` and found type is `&T`, we now look through blocks and suggest dereferencing the expression of the block, rather than the whole block. - In the above case, if the expression is an `&`, we not suggest removing the `&` instead of adding `*`. Both of these are demonstrated in the regression test. Before this patch the first error in the test would be: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ expected `usize`, found `&usize` 9 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 7 | } else *{ 8 | b 9 | }; | Now: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ | | | | | expected `usize`, found `&usize` | | help: consider dereferencing the borrow: `*b` 9 | | }; | |_____- `if` and `else` have incompatible types The second error: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^^ expected integer, found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 13 | } else *{ 14 | &1 15 | }; | now: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^- | | || | | |help: consider removing the `&`: `1` | | expected integer, found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types Fixes rust-lang#82361

lintcheck: fully rerun lintcheck if clippy was rebuilt since last log update Automatically clean lintchecks shared target dir (will force clippy to recheck sources) if the clippy binaries are older than the lintcheck logs. Also updated lintcheck logs in the pr. changelog: lintcheck: fully rerun lintcheck if clippy was rebuilt since last log update

…don't check metadata of directory if it does not exist)

…krgr lintcheck fix build (forgot to pass function parameter) and runtime (… …don't check metadata of directory if it does not exist) Accidentally broke lintcheck in my previous commit. changelog: None

`escape_unicode`, `escape_default`, `len_utf8`, `len_utf16`, to_ascii_lowercase`, `eq_ignore_ascii_case` `u8` methods `to_ascii_lowercase`, `to_ascii_uppercase` also must be made const u8 methods made const Update methods.rs Update mod.rs Update methods.rs Fix `since` in rustc_const_stable to next stable Fix `since` in rustc_const_stable to next stable Update methods.rs Update mod.rs

…1.52.0

Rebases and makes changes required by the recent merge of rust-lang#81837.

Constify intrinsics::forget

Fixes rust-lang#81943

New lint: option_manual_map fixes: rust-lang#6 changelog: Added lint: `match_map`

Co-authored-by: Philipp Krones <hello@philkrones.com>

This is useful for projects that do not use cargo. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

It makes it clearer that the `Namespace` is the one requested by the disambiguator, rather than the actual namespace of the item. It said that in the docs before, but now you can tell in the code so it reduces the potential for confusion.

README: Add subsection on running Clippy as a rustc wrapper This is useful for projects that do not use cargo. changelog: README: Add subsection on running Clippy as a rustc wrapper

Factor out `clippy_utils` crate As discussed in rust-lang/rust-clippy#6746, this PR factors out `clippy_lints::utils` as its own crate, `clippy_utils` . This change will allow `clippy_utils` to be used in lints outside of Clippy. There is no plan to publish this crate on `crates.io` (see rust-lang/rust-clippy#6746 (comment)). Dependent crates should obtain it from GitHub. changelog: Factor out `clippy_utils` so it can be used by external tools (not published)

…-lints, r=flip1995 Move conf.rs back into clippy_lints This is an alternative solution to rust-lang#6785 to fix the CI break caused by rust-lang#6756. changelog: none

Moves the lint back from pedantic to style group. The lint default now only warns on names that are completely capitalized, like "WORD" and only if the name is longer than 2 chars (so that names where each of the letter represents a word are still distinguishable). For example: FP (false positive) would still be "valid" and not warned about (but EOF would warn). A "upper_case_acronyms_aggressive: true/false" config option was added that restores the original lint behaviour to warn on any kind of camel case name that had more than one capital letter following another capital letter.

…ion" lint Fix rust-lang#81663.

Add OpenDNS to `doc-valid-idents` changelog: This commit adds `"OpenDNS"` to doc-valid-idents to avoid `doc_markdown` false positives.

fix sentence / address review comments

…ip1995 move upper_case_acronyms back to style, but make the default behaviour less aggressive by default (can be unleashed via config option) Previous discussion in the bi-weekly clippy meeting for reference: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Meeting.202021-02-23/near/227458019 Move the `upper_case_acronyms` lint back to the style group. Only warn on fully-capitalized names by default. Add add a clippy-config option `upper-case-acronyms-aggressive: true/false` to enabled more aggressive linting on all substrings that could be capitalized acronyms. --- changelog: reenable upper_case_acronyms by default but make the more aggressive linting opt-in via config option

Rustup r? `@ghost` changelog: None

Convert core/num/mod.rs to intra-doc links Helps with rust-lang#75080. This can't convert the associated constants `MAX` and `MIN` until rust-lang#74489 is merged. r? `@poliorcetics`

Use #[doc = include_str!()] in std cc rust-lang#78835 (comment) r? `````@jyn514`````

Add an impl of Error on `Arc<impl Error>`. `Display` already exists so this should be a non-controversial change (famous last words). Would have to be insta-stable.

Make ptr::write const ~~The code in this PR as of right now is not much more than an experiment.~~ ~~This should, if I am not mistaken, in theory compile and pass the tests once the bootstraping compiler is updated. Thus the PR is blocked on that which should happen some time after the February the 9th. Also we might want to wait for rust-lang#79989 to avoid regressing performance due to using `mem::forget` over `intrinsics::forget`~~.

…nup, r=jyn514 rustdoc: Name fields of `ResolutionFailure::WrongNamespace` It makes it clearer that the `Namespace` is the one requested by the disambiguator, rather than the actual namespace of the item. It said that in the docs before, but now you can tell in the code so it reduces the potential for confusion.

…r=oli-obk Account for associated consts in the "unstable assoc item name colission" lint Fix rust-lang#81663.

Make char and u8 methods const char methods `len_utf8`, `len_utf16`, `to_ascii_lowercase`, `eq_ignore_ascii_case` can be made const. `u8` methods `to_ascii_lowercase`, `to_ascii_uppercase` are required to be const as well. `u8::eq_ignore_ascii_case` was additionally made const. Rebase of rust-lang#79549 originally authored by ``@YenForYang.`` Changes from that PR: - Squashed all commits from rust-lang#79549. - rebased to latest upstream master. - Removed const attributes for `char::escape_unicode` and `char::escape_default`. - Updated `since` attributes for `const` stabilization to 1.52.0. cc ``@m-ou-se.``

Fix ICE caused by suggestion with no code substitutions Change suggestion logic to filter and checking _before_ creating specific resolution suggestion. Assert earlier that suggestions contain code substitions to make it easier in the future to debug invalid uses. If we find this becomes too noisy in the wild, we can always make the emitter resilient to these cases and remove the assertions. Fix rust-lang#78651.

…n-here, r=estebank Do not consider using a semicolon inside of a different-crate macro Fixes rust-lang#81943

Slices for vecs

Remove redundant to_string calls

fix the false 'defined here' messages Closes rust-lang#80853. Take this code: ```rust struct S; fn repro_ref(thing: S) { thing(); } ``` Previously, the error message would be this: ``` error[E0618]: expected function, found `S` --> src/lib.rs:4:5 | 3 | fn repro_ref(thing: S) { | ----- `S` defined here 4 | thing(); | ^^^^^-- | | | call expression requires function error: aborting due to previous error ``` This is incorrect as `S` is not defined in the function arguments, `thing` is defined there. With this change, the following is emitted: ``` error[E0618]: expected function, found `S` --> $DIR/80853.rs:4:5 | LL | fn repro_ref(thing: S) { | ----- is of type `S` LL | thing(); | ^^^^^-- | | | call expression requires function | = note: local variable `S` is not a function error: aborting due to previous error ``` As you can see, this error message points out that `thing` is of type `S` and later in a note, that `S` is not a function. This change does seem like a downside for some error messages. Take this example: ``` LL | struct Empty2; | -------------- is of type `Empty2` ``` As you can see, the error message shows that the definition of `Empty2` is of type `Empty2`. Although this isn't wrong, it would be more helpful if it would say something like this (which was there previously): ``` LL | struct Empty2; | -------------- `Empty2` defined here ``` If there is a better way of doing this, where the `Empty2` example would stay the same as without this change, please inform me. **Update: This is now fixed** CC `@camelid`

…umeGomez Update normalize.css to 8.0.1 From From https://github.com/necolas/normalize.css/releases/tag/8.0.1. The old version was 3.0.0, from 2014. The new version is from 2018. I noticed when looking at frontend performance for rustdoc that this file was out of date. The URL in the 3.0.0 license header now resolves to an incorrect destination. And generally it seems good to be up-to-date. Before-and-after images, plus diff, under details. TL;DR: Nothing changes except a slight adjustment to line height. <details> ![with-normalize-8 0 1](https://user-images.githubusercontent.com/220205/108581849-bd5c8800-72e4-11eb-9150-78c8d67ca37a.png) ![with-normalize-3 0 0](https://user-images.githubusercontent.com/220205/108581848-bcc3f180-72e4-11eb-8b45-0cd1415a51e5.png) ![diff](https://user-images.githubusercontent.com/220205/108581890-dfeea100-72e4-11eb-93c5-6284492f54a9.png) </details>

AST: Remove some unnecessary boxes

Improve error msgs when found type is deref of expected This improves help messages in two cases: - When expected type is `T` and found type is `&T`, we now look through blocks and suggest dereferencing the expression of the block, rather than the whole block. - In the above case, if the expression is an `&`, we not suggest removing the `&` instead of adding `*`. Both of these are demonstrated in the regression test. Before this patch the first error in the test would be: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ expected `usize`, found `&usize` 9 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 7 | } else *{ 8 | b 9 | }; | Now: error[E0308]: `if` and `else` have incompatible types --> test.rs:8:9 | 5 | / if true { 6 | | a | | - expected because of this 7 | | } else { 8 | | b | | ^ | | | | | expected `usize`, found `&usize` | | help: consider dereferencing the borrow: `*b` 9 | | }; | |_____- `if` and `else` have incompatible types The second error: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^^ expected integer, found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types | help: consider dereferencing the borrow | 13 | } else *{ 14 | &1 15 | }; | now: error[E0308]: `if` and `else` have incompatible types --> test.rs:14:9 | 11 | / if true { 12 | | 1 | | - expected because of this 13 | | } else { 14 | | &1 | | ^- | | || | | |help: consider removing the `&`: `1` | | expected integer, found `&{integer}` 15 | | }; | |_____- `if` and `else` have incompatible types Fixes rust-lang#82361 --- r? ````@estebank````

Update Clippy Bi-weekly Clippy update. This updates `Cargo.lock`, so probably needs rollup=never. (rust-lang@0046d7c) rust-lang@a6dd9b9 fixes things in Clippy, so that it can be build and tested. This needs proper fixing in Clippy, but I didn't want this to block the sync. r? `@Manishearth`

Commits on Feb 2, 2021

Fix for issue 6640

pag4k committed Feb 2, 2021

Configuration menu

View commit details

Copy full SHA for bfbc083

Browse repository at this point

Copy the full SHA

bfbc083 View commit details

Browse the repository at this point in the history

Commits on Feb 3, 2021

Fixed test

pag4k committed Feb 3, 2021

Configuration menu

View commit details

Copy full SHA for e0e51e4

Browse repository at this point

Copy the full SHA

e0e51e4 View commit details

Browse the repository at this point in the history

Commits on Feb 7, 2021

Simplify DefaultNumericFallback

Y-Nak committed Feb 7, 2021

Configuration menu

View commit details

Copy full SHA for 22d4483

Browse repository at this point

Copy the full SHA

22d4483 View commit details

Browse the repository at this point in the history

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rollup of 16 pull requests #82517

Rollup of 16 pull requests #82517

Commits on Jan 2, 2021

Commits on Jan 3, 2021

Commits on Feb 2, 2021

Commits on Feb 3, 2021

Commits on Feb 4, 2021

Commits on Feb 7, 2021

Commits on Feb 8, 2021

Commits on Feb 10, 2021

Commits on Feb 11, 2021

Commits on Feb 12, 2021

Commits on Feb 13, 2021

Commits on Feb 14, 2021

Commits on Feb 15, 2021

Commits on Feb 16, 2021

Commits on Feb 17, 2021

Commits on Feb 18, 2021

Commits on Feb 19, 2021

Commits on Feb 20, 2021

Commits on Feb 21, 2021

Commits on Feb 22, 2021

Commits on Feb 23, 2021

Commits on Feb 24, 2021

Commits on Feb 25, 2021