Delete the step and the conditional that checks `changes != '[]'`
(`github.event.pull_request.changed_file`s returns the number of files
changed in the pull request - not the list of changed files)
Escape newlines in the comment body safely
Use Bearer instead of deprecated token
changelog: none
Closesrust-lang/rust-clippy#15063
----
changelog: [`op_ref`]: fix wrongly showed macro definition in
suggestions
changelog: [`needless_bool_assign`]: fix missing curlies when on else if
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit`
was ignored, despite the fact that its value should determine the value
of the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
changelog: [`manual_is_variant_and`]: fix inverted suggestions that
could lead to code with different semantics
Fixesrust-lang/rust-clippy#15202
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15206#issuecomment-3034006613)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
Propose to replace `x.map_or(false, |y| y == z)` by `x == Some(z)` only
if `x` is not adjusted. Otherwise, the type of `x` in the comparaison
may not be the expected one, as it may be the product of an auto-deref.
changelog: [`unnecessary_map_or`]: do not propose to replace the
`map_or` call by a comparaison if types wouldn't be correct
Fixesrust-lang/rust-clippy#15180
I think it's pretty common for a lint to be proposed for clippy only for
consensus to be it belongs in rustc, and additionally sometimes bugs get
filed here when the fault is actually with rustc.
https://forge.rust-lang.org/triagebot/transfer.html#issue-transfer
changelog: none
changelog: [`exit`]: When using the `--test` or `--all-targets` flag,
the exit lint should not fail on the main function.
Fixesrust-lang/rust-clippy#13518
With help from @sesgoe
Allow custom default address spaces and parse `p-` specifications in the datalayout string
Some targets, such as CHERI, use as default an address space different from the "normal" default address space `0` (in the case of CHERI, [200 is used](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-877.pdf)). Currently, `rustc` does not allow to specify custom address spaces and does not take into consideration [`p-` specifications in the datalayout string](https://llvm.org/docs/LangRef.html#langref-datalayout).
This patch tries to mitigate these problems by allowing targets to define a custom default address space (while keeping the default value to address space `0`) and adding the code to parse the `p-` specifications in `rustc_abi`. The main changes are that `TargetDataLayout` now uses functions to refer to pointer-related informations, instead of having specific fields for the size and alignment of pointers in the default address space; furthermore, the two `pointer_size` and `pointer_align` fields in `TargetDataLayout` are replaced with an `FxHashMap` that holds info for all the possible address spaces, as parsed by the `p-` specifications.
The potential performance drawbacks of not having ad-hoc fields for the default address space will be tested in this PR's CI run.
r? workingjubilee
compiler: rename BareFn to FnPtr
At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax.
However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
When comparing `x.map(func) == Some(bool_lit)`, the value of `bool_lit` was
ignored, despite the fact that its value should determine the value of
the proposed expression.
`func` can be either a closure or a path. For the latter, η-expansion
will be used if needed to invert the result of the function call.
<strike>build on top of rust-lang/rust-clippy#15071</strike>
This also adds ability to lint Option/Result::and method. Yes, this is
not `or` method, but uses the same eager/lazy linting logic. Should i
update lint description to list all checked structs/methods?
changelog: [`or_fun_call`]: lint Option/Result::and
The `TyCtxt::hir_get_fn_id_for_return_block()` function was too broad,
as it will return positively even when given part of an expression that
can be used as a return value. A new
`potential_return_of_enclosing_body()` utility function has been made to
represent the fact that an expression might be directly returned from
its enclosing body.
changelog: [`return_and_then`]: prevent false positives in case of a
partially used expression
Fixesrust-lang/rust-clippy#15111Fixesrust-lang/rust-clippy#14927
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Beta-nomination](https://github.com/rust-lang/rust-clippy/pull/15115#issuecomment-2996222332)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
This commit also adds more test cases, which already worked but were
mentioned in the issue.
Fixesrust-lang/rust-clippy#9939
changelog: [`manual_let_else`]: correctly handle binding subpattern with
unused name
Fixes: rust-lang/rust-clippy#14897, rust-lang/rust-clippy#10015
This is not a perfect solution, but it fixes the issue. Happy to discuss
further with the clippy team.
This PR refines check_mul_add to avoid false positives on ambiguous
float types (e.g., f32 vs f64). It improves type detection and ensures
mul_add is only suggested when the type is clear.
Changes:
- Improved detection of ambiguous float types
- Refined mul_add suggestion logic
- Added tests for ambiguous cases
## Example
Before this change, expressions like:
```rust
let x = 1.0; // ambiguous type
let _ = x * 2.0 + 0.5; // could incorrectly suggest mul_add
```
----
changelog: [`suboptimal_flops`]: improve handling of ambiguous float
types in mul_add suggestions
Hi,
I noticed that the lint
[neg_multiply](https://rust-lang.github.io/rust-clippy/master/index.html#neg_multiply)
generates bad code when we call a method on the expression.
Consider `((a.delta - 0.5).abs() * -1.0).total_cmp(&1.0)`. Currently
this would be changed by clippy to `-(a.delta - 0.5).abs()
.total_cmp(&1.0)` - which does not compile because we are trying to
negate an ordering enum - but what we really want is `(-(a.delta -
0.5).abs()).total_cmp(&1.0)`.
This PR fixes this.
changelog: [`neg_multiply`] does not remove parenthesis anymore if a
method is being called on the affected expression
NOTE: This is the first time I am contributing to clippy or the rust
repo in general. So I am not sure whether my approach to fixing this
issue is goo, if there are better solutions or if I missed something.
Thanks & hope you have a good day,
Dario
Fixesrust-lang/rust-clippy#9583
When a closure with no parameters is called immediately after being
defined, clippy can now suggest replacing the entire expression with
just the closure's body.
----
changelog: [`redundant_closure_call`]: add fixes for closures with block
While `expr as T` can be removed as a statement if `expr` has no
side-effect, the `as T` part alone cannot be removed if the type of
`expr` would be ambiguous without the cast.
changelog: [`unnecessary_operation`]: do not remove casts if they are
useful to type the expression
Fixesrust-lang/rust-clippy#15173
Turns out that things like `#[attr]return unsafe { func(); }` didn't
work because we weren't checking above attributes on statements, only on
blocks!
fixes https://github.com/rust-lang/rust-clippy/issues/13189
Useful for Rust-For-Linux
changelog:[`undocumented_unsafe_blocks`]: Make sure to propagate
`accept-comment-above-attributes` to **all** statements.
As I said in my on-vacation PR (a little bit late) I'm getting
reincorporated into the review queue. Something that I'd like to do is
implement the reviewer capacity system into Clippy, but seems that it's
not supported yet. https://github.com/rust-lang/triagebot/issues/2007
r? @ghost
changelog:none
Make -Ztrack-diagnostics emit like a note
[#t-compiler/diagnostics > Rendering -Ztrack-diagnostics like a note](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/Rendering.20-Ztrack-diagnostics.20like.20a.20note/with/526608647)
As discussed on the Zulip thread above, I want to make `-Ztrack-diagnostics` emit like a `note`. This is because I find its current output jarring, and the fact that it gets rendered completely left-aligned, [even in the middle of a snippet](86e05cd300/tests/ui/track-diagnostics/track6.stderr), seems like something that should be changed. Turning it into a `note` seems like the best choice, as it would align it with the rest of the output, and `note` is already used for somewhat similar things, like seeing why a lint was fired.
---
Note: turning `-Ztrack-diagnostics` into a `note` will also make `annotate-snippets` API a bit cleaner
Follow-up of rust-lang/rust-clippy#15140.
This time, I removed some unneeded `<span>` wrappings and some unneeded
CSS classes. As usual, no changes in the UI.
Before this PR: 1876091
With this PR: 1751097
Reduction: -6.6%
r? @samueltardieu
changelog: Reduce page size and number of DOM elements on clippy lints
page
This is the first pass of "reducing the size of the clippy lints page"
I'm currently going through. This first one reduces the size page but
mostly reduces the number of DOM elements.
Page size change:
* Before this PR: 1938957
* With this PR: 1876167
* Reduction: -3.2%
r? @Alexendoo
changelog: Reduce page size and number of DOM elements on clippy lints
page
