Fix several issues with `manual_is_multiple_of`
- `&a % &b == 0` compiles, but requires dereferencing `b` when replacing
with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain, `a.is_multiple_of(b)`
might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
arbitrary types implementing `Rem` and outputing an integer.
Those fixes have required increasing the precision of type certainty
determination in the two first patches.
Fixesrust-lang/rust-clippy#15203Fixesrust-lang/rust-clippy#15204
changelog: [`manual_is_multiple_of`]: fix various false positive
<strike>blocked on rust-lang/rust-clippy#15073</strike>
Lint method calls inside `map_or` too, so for this, lint will be showed:
```rust
Some(4).map_or("asd".to_string().len() as i32, f);
```
previously it worked only for:
```rust
Some(4).map_or(slow_fun(), f);
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=bfcda42a6af446e69bc883a8b45eb13c
Sorry for multiple `or_fun_call` PRs.
changelog: [`or_fun_call`]: lint method calls inside map_or first arg
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.
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 -->
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
`Node::Param(…)` can represent function parameters as well as closure
parameters. In the second case, a type is not always given. When no
type is given, consider it uncertain.
However, if they appear within the context of a function argument, they
will be marked as certain, as they might eventually be considered `i32`
by default if the context is not more specific.
Also, in the case of binary expressions, if one of the side is
uncertain, then the certainty will come from the other side.
Add `track_caller` attributes to trace origin of Clippy lints
This allows the use of `-Z track-diagnostics` to see the origin of Clippy lints emission, as is already the case for lints coming from rustc.
It's like `Symbol` but for byte strings. The interner is now used for
both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"`
you'll get a `Symbol` and a `ByteSymbol` with the same index and the
characters will only be stored once.
The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to
make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate
`ast::LitKind` in HIR. The latter change reduces peak memory by a
non-trivial amount on literal-heavy benchmarks such as `deep-vector` and
`tuple-stress`.
`Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some
changes so that they can handle normal strings and byte strings.
This change does slow down compilation of programs that use
`include_bytes!` on large files, because the contents of those files are
now interned (hashed). This makes `include_bytes!` more similar to
`include_str!`, though `include_bytes!` contents still aren't escaped,
and hashing is still much cheaper than escaping.
The lint was extra restrictive, and didn't suggest using
`core::ptr::null` and `core::ptr::null_mut` in `const` contexts although
they have been const-stabilized since Rust 1.24.
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.
For example, adding `*` in front of `*expression` is best shown as
`**expression` rather than `*(*expression)`.
This is not perfect, as it checks whether the operator is already a
prefix of the expression, but it is better than it was before. For
example, `&`+`&mut x` will get `&&mut x` but `&mut `+`&x` will get `&mut
(&x)` as it did before this change.
changelog: none
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from
`libc`.
I don't really trust callgrind when it says I've turn 81 billion
instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20
times
without incr" method and it went from 0.31s-0.45s to 0.25s
constistently.
(Profiled, and "benchmarked") on tokio.
What I can get behind is via `strlen_on_c_strings` changing from 31
million instructions into 76k. 🎉🥳
changelog: [`strlen_on_c_strings`]: Optimize it by 99.75%
So this is funny, the query `tcx.module_children` was top 3 in most
time consuming functions in Clippy, it was being called 24384 times in
tokio. "Unacceptable!" I thought. Digging a bit around, turns out that
`clippy::strlen_on_c_strings` was calling for `get_def_path` via
`match_libc_symbol`. This query pretty-prints things and performs some
analysis.
Yes, we were running early lint checks to see if symbols were from `libc`.
I don't really trust callgrind when it says I've turn 81 billion instructions
into like 10 million. So I benchmarked this the good ol' "compiling 20 times
without incr" method and it went from 0.31s-0.45s to 0.25s constistently.
(Profiled, and "benchmarked") on tokio.
