bors [Wed, 6 Oct 2021 07:38:38 +0000 (07:38 +0000)]
Auto merge of #7773 - Manishearth:update-lints-mods, r=flip1995
Move module declarations back into lib.rs
With #7673 we moved a lot of things from lib.rs to lib.foo.rs. Unfortunately, rustfmt doesn't seem to work when module declarations are included via `include!` (and trying the `mod foo; use foo::*;` trick doesn't seem to work much either in our specific case).
With this PR we continue generating everything in subfiles except for module declarations, which are now generated within lib.rs.
bors [Tue, 5 Oct 2021 19:51:09 +0000 (19:51 +0000)]
Auto merge of #7770 - zvavybir:master, r=xFrednet
improved help message for `suspicious_map`
`suspicious_map`'s help message assumes that the literal behavior is never the intended one, although it's sometimes. This PR adds a mention of `inspect`, offering a idiomatic alternative.
fixes #7767
---
changelog: Improved help message of [`suspicious_map`].
bors [Mon, 4 Oct 2021 19:38:04 +0000 (19:38 +0000)]
Auto merge of #7762 - HKalbasi:master, r=Manishearth
Add lint `equatable_if_let`
This is my attempt for #1716. There is a major false positive, which is people may implement `PartialEq` in a different way. It is unactionable at the moment so I put it into `nursery`.
There is a trait `StructuralPartialEq` for solving this problem which is promising but it has several problems currently:
* Integers and tuples doesn't implement it.
* Some types wrongly implement it, like `Option<T>` when `T` doesn't implement it.
I consider them bugs and against the propose of `StructuralPartialEq`. When they become fixed, this lint can become a useful lint with a single line change.
bors [Sun, 3 Oct 2021 21:44:10 +0000 (21:44 +0000)]
Auto merge of #88175 - camsteffen:let-desugar-span, r=Manishearth
Add expansion to while desugar spans
In the same vein as #88163, this reverts a change in Clippy behavior as a result of #80357 (and reverts some `#[allow]`s): This changes `clippy::blocks_in_if_conditions` to not fire on `while` loops. Though we might actually want Clippy to lint those cases, we should introduce the change purposefully, with tests, and possibly under a different lint name.
The actual change here is to add a desugaring expansion to the spans when lowering a `while` loop.
bors [Fri, 1 Oct 2021 22:47:22 +0000 (22:47 +0000)]
Auto merge of #89449 - Manishearth:rollup-3alb61f, r=Manishearth
Rollup of 7 pull requests
Successful merges:
- #85223 (rustdoc: Clarified the attribute which prompts the warning)
- #88847 (platform-support.md: correct ARMv7+MUSL platform triple notes)
- #88963 (Coerce const FnDefs to implement const Fn traits )
- #89376 (Fix use after drop in self-profile with llvm events)
- #89422 (Replace whitespaces in doctests' name with dashes)
- #89440 (Clarify a sentence in the documentation of Vec (#84488))
- #89441 (Normalize after substituting via `field.ty()`)
Rollup merge of #88782 - asquared31415:issue-79559, r=cjgillot
Fix ICE when `start` lang item has wrong generics
In my previous pr #87875 I missed the requirements on the `start` lang item due to its relative difficulty to test and opting for more conservative estimates. This fixes that by updating the requirement to be exactly one generic type.
The `start` lang item should have exactly one generic type for the return type of the `main` fn ptr passed to it. I believe having zero would previously *sometimes* compile (often with the use of `fn() -> ()` as the fn ptr but it was likely UB to call if the return type of `main` was not `()` as far as I know) however it also sometimes would not for various errors including ICEs and LLVM errors depending on exact situations. Having more than 1 generic has always failed with an ICE because only the one generic type is expected and provided.
Because https://github.com/rust-lang/rust/blob/6cdd42f9f8dd4e5e5ba0aa816bc4c99ab8b102f9/library/std/src/primitive_docs.rs#L538
/// Arrays of sizes from 0 to 32 (inclusive) implement [`Default`] trait
/// if the element type allows it. As a stopgap, trait implementations are
/// statically generated up to size 32.
So here to detect this situation.
changelog: [`derivable_impls`]: No longer lints when arrays bigger than 32 elements are involved
This needs a review this time. Especially https://github.com/rust-lang/rust-clippy/commit/521bf8f0fa18c7f130505f0a902ab0e65a76cec2 cc `@camsteffen` I think this is necessary now, because `itertools` is no longer a dependency of `clippy_utils` and therefore this path can't be found :thinking:
( I forgot about the sync last week. I should get to document this process better, so other people can do it when I'm not around )
Auto merge of #7608 - andrewpollack:7594/while_let_some_result, r=Manishearth
#7594: Adding new 'while_let_some_result' linting
Excited for the opportunity to contribute to Clippy! Since the latest Bay Area Rust Meetup, I've been looking for an opportunity and found it :smile:
Please let me know how I can improve this PR! Much of it is similar to ``[`if_let_some_result`]``, but I followed the description in the issue to create its own linting rules. Looking forward to feedback, and continuing to work on Clippy in the future!
changelog: Renamed Lint: `if_let_some_result` is now called [`match_result_ok`]. Now also handles `while let` case.
Auto merge of #7692 - workingjubilee:float-cmp-not-wrong, r=giraffate
Demote float_cmp to pedantic
See this issue: https://github.com/rust-lang/rust-clippy/issues/7666
This is one of the most frequently suppressed lints. It is deny-by-default. It is not actually clearly wrong, as there are many instances where direct float comparison is actually desirable. It is only after operating on floats that they may lose precision, and that depends greatly on the operation. As most correctness lints have a much higher standard of error, being based on hard and fast binary logic, this should not be amongst them.
A linter is not a substitute for observing the math carefully and running tests, and doing the desirable thing is even more likely to lead one to want exact comparisons.
changelog: Demote [`float_cmp`] from correctness to pedantic lints
Auto merge of #7722 - dtolnay-contrib:float, r=giraffate
Stop suggesting a float truncation that is not shorter
Fixes #7721.
Previously Clippy would say that a number has excessive precision even if it has the minimum possible precision for the floating point value that it corresponds to.
changelog: Fix [`excessive_precision`] being triggered on floats that are already written in shortest form
projects / rust.git / log