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
Auto merge of #89030 - nbdd0121:box2, r=jonas-schievink
Introduce `Rvalue::ShallowInitBox`
Polished version of #88700.
Implements MCP rust-lang/compiler-team#460, and should allow #43596 to go forward.
In short, creating an empty box is split from a nullary-op `NullOp::Box` into two steps, first a call to `exchange_malloc`, then a `Rvalue::ShallowInitBox` which transmutes `*mut u8` to a shallow-initialized `Box<T>`. This allows the `exchange_malloc` call to unwind. Details can be found in the MCP.
`NullOp::Box` is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient.
Experiments in #88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-`oom=panic` case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.
Rollup merge of #89001 - jackh726:binder-cleanup, r=nikomatsakis
Be explicit about using Binder::dummy
This is somewhat of a late followup to the binder refactor PR. It removes `ToPredicate` and `ToPolyTraitImpls` that hide the use of `Binder::dummy`. While this does make code a bit more verbose, it allows us be more careful about where we create binders.
Another alternative here might be to add a new trait `ToBinder` or something with a `dummy()` fn. Which could still allow grepping but allows doing something like `trait_ref.dummy()` (but I also wonder if longer-term, it would be better to be even more explicit with a `bind_with_vars(ty::List::empty())` *but* that's not clear yet.
projects / rust.git / log