`non_canonical_partial_ord_impl` will now recognize two forms of
canonical implementations: `Some(self.cmp(other))` and
`self.cmp(other).into()`.
changelog: [`non_canonical_partial_ord_impl`]: recognize
`self.cmp(other).into()` as a canonical implementation of
`PartialOrd::partial_cmp()`.
Fixesrust-lang/rust-clippy#13640
Fixes rust-lang/rust-clippy#14449, introduced in #14314
changelog: [`map_entry`]: fix a false positive where the lint would
trigger without any insert calls present
changelog: [`manual_abs_diff`]: Initial implementation
Hey, first time writing a new lint for clippy, hope I got it right. I
think it's pretty self-explanatory!
Added a few `fixme` test cases, where the lint can be improved to catch
more (probably rare) patterns, but opening a PR with this initial
implementation to make sure I'm on the right track, and that this lint
is acceptable at all.
😁
Straight from triagebot's documentation, this should allow the bot to
set and remove the `S-waiting-on-author` and `S-waiting-on-review`
labels when a PR author requests a review, or when a review is done with
changes requested.
We do not want to remove casts done inside macros. Also, when printing
the suggestion, take it from the same context as the origin expression
(the root context).
Problems found while working on #14526, but should be merged even if
#14526 is not.
changelog: none
This PR enables to the canonicalization of issue links in triagebot.
Documentation pending at
https://github.com/rust-lang/rust-forge/pull/825
changelog: add `[canonicalize-issue-links]` in `triagebot.toml`
This PR fixes issues with the `missing_asserts_for_indexing` lint.
- false positive when the first index is the highest(or equal) value in
a list of indexes:
```rust
pub fn foo(slice: &[i32]) -> i32{
slice[1] * slice[0]
}
```
- false negative when an assert statement if found after the indexing
operation.
```rust
pub fn bar(slice: &[i32]) -> i32 {
let product = slice[0] * slice[1];
assert!(slice.len() > 1);
product
}
```
examples: https://godbolt.org/z/s7Y47vKdEcloses: #14079
changelog: [`missing_asserts_for_indexing`]: ignore asserts found after
indexing, and do not require asserts if the first index is highest.
Not all host tools platforms support `f16`/`f128` builtins yet due to
LLVM assertion failures and miscompilations. Until them, Clippy should
avoid using `f16`/`f128` at runtime itself. See
https://github.com/rust-lang/rust/issues/137630.
cc @tgross35
changelog: none
We do not want to remove casts done inside macros. Also, when printing
the suggestion, take it from the same context as the origin expression
(the root context).
r? @flip1995
After seeing some PRs get relabelled I think it's probably for the best
not to, a conflict doesn't mean it's no longer waiting for review after
all
changelog: none
Move methods from `Map` to `TyCtxt`, part 5.
This eliminates all methods on `Map`. Actually removing `Map` will occur in a follow-up PR.
A follow-up to #137504.
r? `@Zalathar`
Various local trait item iteration cleanups
Adding a trait impl for `Foo` unconditionally affected all queries that are interested in a completely independent trait `Bar`. Perf has no effect on this. We probably don't have a good perf test for this tho.
r? `@compiler-errors`
I am unsure about https://github.com/rust-lang/rust/pull/139018/commits/9d05efb66f7b599eeacb5d2456f844fe4768e865 as it doesn't improve anything wrt incremental, because we still do all the checks for valid `Drop` impls, which subsequently will still invoke many queries and basically keep the depgraph the same.
I want to do
9549077a47/compiler/rustc_middle/src/ty/trait_def.rs (L141)
but would leave that to a follow-up PR, this one changes enough things as it is
This PR resolves#11432 by checking that paths resolve in `disallowed_*`
configurations.
It also does some lightweight validation of definition kinds. For
example, only paths that resolve to `DefKind::Macro` definitions are
allowed in `disallowed_macro` configurations.
~The PR is currently two commits. The first is #14376 (cc: @Jarcho),
which I submitted just a few days ago. The second commit is everything
else.~
Side note: For me, the most difficult part of this PR was getting the
spans of the individual `DisallowedPath` configurations. There is some
discussion at https://github.com/toml-rs/toml/discussions/840, if
interested.
changelog: validate paths in `disallowed_*` configurations
Fixes#14488
Context: the `macro_metavars_in_unsafe` lint looks for unsafe blocks
with a macro span that then contain expressions with a root context span
(which means that it is a macro with an unsafe block expanding a
metavariable inside). In order to avoid emitting a warning for every
single macro invocation, it will deduplicate the unsafe blocks by the
span in the macro.
This leads to the linked issue where because of the deduplicating and
removing unsafe blocks that all belong to the same unsafe block in the
macro, only one of the unsafe blocks will actually have its lint
expectation fulfilled. This PR fixes that by manually fulfilling all of
the unsafe blocks from all expansions before deduplicating them.
changelog: [`macro_metavars_in_unsafe`]: fix unfulfilled `#[expect]` if
macro is invoked multiple times
A discrepancy between the `cmake` version available on the runners and
the one required by the `aws-lc-sys` dependency prevents the crate from
building.
changelog: none
r? @flip1995
cc @Alexendoo
A discrepancy between the `cmake` version available on the runners and
the one required by the `aws-lc-sys` dependency prevents the crate from
buiding.
Found this while reviewing PR
https://github.com/rust-lang/rust/pull/138384: See
https://github.com/rust-lang/rust/pull/138384#discussion_r1996111087 in
which I suggested a FIXME to be added that I'm now fixing in this PR.
---
Before this PR, `redundant_pub_crate` computed a broken primary Span
when flagging items (`hir::Item`s) that never bear a name (`ForeignMod`,
`GlobalAsm`, `Impl`, `Use(UseKind::Glob)`, `Use(UseKind::ListStem)`).
Namely, it created a span whose high byte index is `DUMMY_SP.hi()` which
is quite broken (`DUMMY_SP` is synonymous with `0..0` wrt. the entire
`SourceMap` meaning it points at the start of the very first source file
in the `SourceMap`).
Why did this happen? Before PR
https://github.com/rust-lang/rust/pull/138384, the offending line looked
like `let span = item.span.with_hi(item.ident.span.hi());`. For nameless
items, `item.ident` used to be set to `Ident(sym::empty, DUMMY_SP)`.
This is where the `DUMMY_SP` came from.
The code means to compute a "shorter item span" that doesn't include the
"body" of items, only the "head" (similar to `TyCtxt::def_span`).
<details><summary>Examples of Clippy's butchered output on
master</summary>
```rs
#![deny(clippy::redundant_pub_crate)]
mod m5 {
pub mod m5_1 {}
pub(crate) use m5_1::*;
}
```
```
error: pub(crate) import inside private module
--> file.rs:1:1
|
1 | / #![deny(clippy::redundant_pub_crate)]
2 | |
3 | | mod m5 {
4 | | pub mod m5_1 {}
5 | | pub(crate) use m5_1::*;
| | ^---------- help: consider using: `pub`
| |____|
|
```
Or if the `SourceMap` contains multiple files (notice how it leaks
`clippy.toml`!):
```
error: pub(crate) import inside private module
--> /home/fmease/programming/rust/clippy/clippy.toml:1:1
|
1 | / avoid-breaking-exported-api = false
2 | |
3 | | check-inconsistent-struct-field-initializers = true
... |
6 | |
| |_^
|
::: file.rs:6:5
|
6 | pub(crate) use m5_1::{*}; // Glob
| ---------- help: consider using: `pub`
|
```
</details>
---
**Note**: Currently, the only nameless item kind that can also have a
visibility is `Use(UseKind::{Glob,ListStem})`. Thus I'm just falling
back to the entire item's Span which wouldn't be that verbose. However,
in the future Rust will feature impl restrictions (like `pub(crate) impl
Trait for Type {}`, see [RFC
3323](https://rust-lang.github.io/rfcs/3323-restrictions.html) and
https://github.com/rust-lang/rust/pull/106074). Using `item.span` for
these would be quite bad (it would include all associated items). Should
I add a FIXME?
---
changelog: [`redundant_pub_crate`]: Fix the code highlighting for
nameless items.
`tokio-rustls` requires `aws-lc-sys` which requires `cmake 3.x` to be
built. This installs `cmake 3.x` from the repository, overriding the
`cmake 4.x` installation.
The situation will be reexamined in a few weeks, as `aws-lc-sys` will
get a new release in a few days with `cmake 4.x` support. We will then
be able to remove this temporary fix.
changelog: none
r? @ghost
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
