#2597 appears to be already resolved, so the applicability of `op_ref`
can be set to `MachineApplicable`.
close#2597
changelog: [`op_ref`]: set the applicability to `MachineApplicable`
Closes#11346.
Partially fix#9905. The first case in this issue is a little tricky as
the coerce does not happen in the borrowing.
changelog: [`borrow_deref_ref`]: fix wrong suggestions when coerce to
mut
By default, lintcheck will use the `clippy.toml` file found at the
toplevel of the repository (`CARGO_MANIFEST_DIR`). This file is meant
for configuration of Clippy applied to Clippy sources.
This creates a new `lintcheck/ci-config/clippy.toml` file which is used
by the CI when running lintcheck. By default this uses the default
Clippy configuration.
changelog: none
Closes#11617Closes#14368
Clippy gives wrong suggestions when the filter and then cannot be put
into closure directly. Since trying to transform these can be too
complicated, Clippy will simply warn but don't try to fix.
changelog: [`filter_map_bool_then`]: fix wrong suggestions when the
closure cannot be decompose directly
The configuration of the toolchain using `rust-toolchain` is only
retained for backward compatibility, and it is recommended to explicitly
specify the TOML format, as in `rust-toolchain.toml`.
r? flip1995
(This is because the change affects the sync process, and you are the
one responsible for sync (I believe).)
changelog: none
The applicability of `never_loop` is currently set to `Unspecified`, but
if the loop block does not contain `break` or `continue`, it can be
`MachineApplicable`.
changelog: [`never_loop`]: the applicability is now `MachineApplicable`
when the loop block contains neither `break` nor `continue`
fixes#13964
The lint `option_map_unwrap_or` used to have a similar issue in #10579,
so I borrowed its solution to fix this one.
changelog: [`option_if_let_else`]: fix FP when value partially moved
TLDR
```diff
- /// 01234
+ /// 01234
12345
```
Sometimes, in doc comments, there are 3 spaces + 1 instead of 4 spaces +
1.
To make it coherent with the rest of the clippy codebase, I `fd -t f -X
sed -E -i 's,///\s{4}(\S),/// \1,g'` and manually verified and fixed the
relevant part of code that had bad indentation.
### Example
```rs
/// fn a() {
/// 01234
/// }
```
Becomes
```rs
/// fn a() {
/// 01234
/// }
```
changelog: none
Commit efe3fe9b8c removed the ability for
`single_match` and `single_match_else` to trigger if comments were
present outside of the arms, as those comments would be lost while
rewriting the `match` expression.
This reinstates the lint, but prevents the suggestion from being applied
automatically in the presence of comments by using the `MaybeIncorrect`
applicability. Also, a note is added to the lint message to warn the
user about the need to preserve the comments if acting upon the
suggestion.
changelog: [`single_match`, `single_match_else`]: reinstate lint when
comments are inside the `match` but do not autofix the code
Fix#14418
I love this project but I (again) don't have the time nor energy at the
moment. Will go through my current assignments over time and still
review occasionally.
PS: sorry about the branch on upstream!
changelog: none
Fixes https://github.com/rust-lang/rust-clippy/issues/14175.
There are two "big" cases to handle: `.map(|x| x.to_string())` and
`.map(String::to_string)`. If the closure has more than one expression,
we should not suggest `.cloned()`.
changelog: Improve `string_to_string` lint in case it is in a map call
r? @samueltardieu
Rollup of 7 pull requests
Successful merges:
- #138384 (Move `hir::Item::ident` into `hir::ItemKind`.)
- #138508 (Clarify "owned data" in E0515.md)
- #138531 (Store test diffs in job summaries and improve analysis formatting)
- #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly)
- #138556 (Fix ICE: attempted to remap an already remapped filename)
- #138608 (rustc_target: Add target feature constraints for LoongArch)
- #138619 (Flatten `if`s in `rustc_codegen_ssa`)
r? `@ghost`
`@rustbot` modify labels: rollup
I love this project but I (again) don't have the time nor energy at the moment. Will go through my current assignments over time and still review occasionally.
`hir::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Macro`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
Trait`, TraitAalis`.
- It's always empty for these item kinds: `ForeignMod`, `GlobalAsm`,
`Impl`.
- For `Use`, it is non-empty for `UseKind::Single` and empty for
`UseKind::{Glob,ListStem}`.
All of this is quite non-obvious; the only documentation is a single
comment saying "The name might be a dummy name in case of anonymous
items". Some sites that handle items check for an empty ident, some
don't. This is a very C-like way of doing things, but this is Rust, we
have sum types, we can do this properly and never forget to check for
the exceptional case and never YOLO possibly empty identifiers (or
possibly dummy spans) around and hope that things will work out.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- A similar transformation makes sense for `ast::Item`, but this is
already a big change. That can be done later.
- Lots of assertions are added to item lowering to ensure that
identifiers are empty/non-empty as expected. These will be removable
when `ast::Item` is done later.
- `ItemKind::Use` doesn't get an `Ident`, but `UseKind::Single` does.
- `lower_use_tree` is significantly simpler. No more confusing `&mut
Ident` to deal with.
- `ItemKind::ident` is a new method, it returns an `Option<Ident>`. It's
used with `unwrap` in a few places; sometimes it's hard to tell
exactly which item kinds might occur. None of these unwraps fail on
the test suite. It's conceivable that some might fail on alternative
input. We can deal with those if/when they happen.
- In `trait_path` the `find_map`/`if let` is replaced with a loop, and
things end up much clearer that way.
- `named_span` no longer checks for an empty name; instead the call site
now checks for a missing identifier if necessary.
- `maybe_inline_local` doesn't need the `glob` argument, it can be
computed in-function from the `renamed` argument.
- `arbitrary_source_item_ordering::check_mod` had a big `if` statement
that was just getting the ident from the item kinds that had one. It
could be mostly replaced by a single call to the new `ItemKind::ident`
method.
- `ItemKind` grows from 56 to 64 bytes, but `Item` stays the same size,
and that's what matters, because `ItemKind` only occurs within `Item`.
Commit efe3fe9b8c removed the ability for
`single_match` and `single_match_else` to trigger if comments were
present outside of the arms, as those comments would be lost while
rewriting the `match` expression.
This reinstates the lint, but prevents the suggestion from being applied
automatically in the presence of comments by using the `MaybeIncorrect`
applicability. Also, a note is added to the lint message to warn the
user about the need to preserve the comments if acting upon the
suggestion.
It determines if a function should have any `inline` attributes checked.
For `ItemKind::Fn` it returns true or false depending on the details of
the function; for anything other item kind it returns *true*. This
latter case should instead be *false*. (In the nearby and similar
functions `is_relevant_impl` and `is_relevant_trait` the non-function
cases return false.)
The effect of this is that non-functions are no longer checked. But
rustc already disallows `inline` on any non-function items. So if
anything its a tiny performance win, because that was useless anyway.
Sometimes, in doc comments, there are 3 spaces + 1 instead of 4 spaces + 1.
To make it coherent with the rest of the clippy codebase, I `fd -t f -X sed -E -i 's,/// (\S),/// \1,g'` and manually verified and fixed the relevant part of code that had bad indentation.
close#12157
`needless_return` sometimes makes incorrect suggestions by omitting
necessary enclosing parentheses. This PR resolves the issue by using
`clippy_utils::sugg::Sugg`.
changelog: [`needless_return`]: now makes correct suggestions which
require enclosing parentheses
Fixes https://github.com/rust-lang/rust-clippy/issues/12163
I decided to initially make this a restriction lint because it felt a
bit niche and opinionated to be a warn-by-default style lint. It may be
appropriate as a style lint if the standard or convention *is* to use
`\` as doc comment linebreaks - not sure if they are!
The wording on the help message could be improved, as well as the name
of the lint itself since it's a bit wordy - suggestions welcome.
This lint works on both `///` and `//!` doc comments.
changelog: new lint: `doc_comment_double_space_linebreaks`
Use `rustc_type_ir` directly less in the codebase
cc https://github.com/rust-lang/rust/issues/138449
This is a somewhat opinionated bundle of changes that will make working on https://github.com/rust-lang/rust/issues/138449 more easy, since it cuts out the bulk of the changes that would be necessitated by the lint. Namely:
1. Fold `rustc_middle::ty::fold` and `rustc_middle::ty::visit` into `rustc_middle::ty`. This is because we already reexport some parts of these modules into `rustc_middle::ty`, and there's really no benefit from namespacing away the rest of these modules's functionality given how important folding and visiting is to the type layer.
2. Rename `{Decodable,Encodable}_Generic` to `{Decodable,Encodable}_NoContext`[^why], change it to be "perfect derive" (`synstructure::AddBounds::Fields`), use it throughout `rustc_type_ir` instead of `TyEncodable`/`TyDecodable`.
3. Make `TyEncodable` and `TyDecodable` derives use `::rustc_middle::ty::codec::TyEncoder` (etc) for its generated paths, and move the `rustc_type_ir::codec` module back to `rustc_middle::ty::codec` 🎉.
4. Stop using `rustc_type_ir` in crates that aren't "fundamental" to the type system, namely middle/infer/trait-selection. This amounted mostly to changing imports from `use rustc_type_ir::...` to `use rustc_middle::ty::...`, but also this means that we can't glob import `TyKind::*` since the reexport into `rustc_middle::ty::TyKind` is a type alias. Instead, use the prefixed variants like `ty::Str` everywhere -- IMO this is a good change, since it makes it more regularized with most of the rest of the compiler.
[^why]: `_NoContext` is the name for derive macros with no additional generic bounds and which do "perfect derive" by generating bounds based on field types. See `HashStable_NoContext`.
I'm happy to cut out some of these changes into separate PRs to make landing it a bit easier, though I don't expect to have much trouble with bitrot.
r? lcnr
