Liberate late-bound regions rather than erasing them in `needless_pass_by_value`
changelog: [`needless_pass_by_value`]: fixes an ICE when there are late-bound regions in function arguments that are needlessly passed by value
Fixesrust-lang/rust#107147
r? `@matthiaskrgr`
It is not sufficient to ignore break from a block inside the loop.
Instructions after the break must be ignored, as they are unreachable.
This is also true for all instructions in outer blocks and loops
until the right block is reached.
This lint complains when the question mark operator (try operator)
is used. This is a restriction lint that can be useful on local
scopes where a custom error handling macro is supposed to be used
to augment the error based on local scope data before returning.
Introduce `-Zterminal-urls` to use OSC8 for error codes
Terminals supporting the OSC8 Hyperlink Extension can support inline anchors where the text is user defineable but clicking on it opens a browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Terminals supporting the OSC8 Hyperlink Extension can support inline
anchors where the text is user defineable but clicking on it opens a
browser to a specified URLs, just like `<a href="URL">` does in HTML.
https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
Make `[clippy::dump]` support trait items
Roses are red,
violets are blue,
trait items are rare,
`[clippy::dump]` is too
---
Let's just ignore the horrible poem... anyways. While working on Marker I noticed, that `[clippy::dump]` doesn't work on trait item (See [Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e2d9791ffa2872e7c09a9dfbd470350c)). This simply adds support for that. `[clippy::dump]` doesn't have UI tests, to make it more resistant to changes in the AST. I tested it locally and the dump works after these changes.
---
changelog: none
Negate suggestions when needed in `bool_assert_comparison`
changelog: none assuming this gets into the same release as #10218Fixes#10291
r? `@dswij`
Thanks to `@black-puppydog` for spotting it early
wildcard_enum_match_arm lint takes the enum origin into account
fixes#7419
---
changelog: Enhancement: [`wildcard_enum_match_arm`]: Now lints missing private variants, for local enums
[#10250](https://github.com/rust-lang/rust-clippy/pull/10250)
<!-- changelog_checked -->
Fix version declared for semicolon_inside_block and semicolon_outside…
As per Issue #10244, the lint were documentated
as being part of 1.66.0 but will actually be
released 1.68.0 .
changelog: [`semicolon_inside_block`]: Documentation fix
Fixes#10244
Mark uninlined_format_args as pedantic
Fixes https://github.com/rust-lang/rust-clippy/issues/10087
We should restore this when rust-analyzer support gets better. Worth filing an issue to track.
changelog: Mark [`uninlined_format_args`] as `pedantic`
[`unused_io_amount`]: Lint with `is_ok` and `is_err`
Fixes#10132
changelog: Apply [`unused_io_amount`] lint to `is_ok` and `is_err` without checking read/write amount
prevents `len_without_is_empty` from yielding positive when `len` takes arguments besides `&self`
Fixes#9520
---
changelog: FP [`len_without_is_empty`]: No longer lints, if `len` as a non-default signature
[#10255](https://github.com/rust-lang/rust-clippy/pull/10255)
<!-- changelog_checked -->
more than just `&self` in non-standard implementations.
changelog: Fix [`len_without_is_empty`] false positive when len has a
non-standard method signature
Fixes#9520
`invalid_regex`: Show full error when string value doesn't match source
changelog: [`invalid_regex`]: Show full error when parsing non-literals or regular strings containing escape sequences
Fixes#4170, the escape sequence there causes the span to be incorrect which will have caused most of the confusion
Remove HirId -> LocalDefId map from HIR.
Having this map in HIR prevents the creating of new definitions after HIR has been built.
Thankfully, we do not need it.
Based on https://github.com/rust-lang/rust/pull/103902
Remove `ControlFlow::{BREAK, CONTINUE}`
Libs-API decided to remove these in #102697.
Follow-up to #107023, which removed them from `compiler/`, but a couple new ones showed up since that was merged.
r? libs
Remove overlapping parts of multipart suggestions
This PR adds a debug assertion that the parts of a single substitution cannot overlap, fixes a overlapping substitution from the testsuite, and fixes https://github.com/rust-lang/rust/issues/106870.
Note that a single suggestion can still have multiple overlapping substitutions / possible edits, we just don't suggest overlapping replacements in a single edit anymore.
I've also included a fix for an unrelated bug where rustfix for `explicit_outlives_requirements` would produce multiple trailing commas for a where clause.
Compute generator saved locals on MIR
Generators are currently type-checked by introducing a `witness` type variable, which is unified with a `GeneratorWitness(captured types)` whose purpose is to ensure that the auto traits correctly migrate from the captured types to the `witness` type. This requires computing the captured types on HIR during type-checking, only to re-do it on MIR later.
This PR proposes to drop the HIR-based computation, and only keep the MIR one. This is done in 3 steps.
1. During type-checking, the `witness` type variable is never unified. This allows to stall all the obligations that depend on it until the end of type-checking. Then, the stalled obligations are marked as successful, and saved into the typeck results for later verification.
2. At type-checking writeback, `witness` is replaced by `GeneratorWitnessMIR(def_id, substs)`. From this point on, all trait selection involving `GeneratorWitnessMIR` will fetch the MIR-computed locals, similar to what opaque types do. There is no lifetime to be preserved here: we consider all the lifetimes appearing in this witness type to be higher-ranked.
3. After borrowck, the stashed obligations are verified against the actually computed types, in the `check_generator_obligations` query. If any obligation was wrongly marked as fulfilled in step 1, it should be reported here.
There are still many issues:
- ~I am not too happy having to filter out some locals from the checked bounds, I think this is MIR building that introduces raw pointers polluting the analysis;~ solved by a check specific to static variables.
- the diagnostics for captured types don't show where they are used/dropped;
- I do not attempt to support chalk.
cc `@eholk` `@jyn514` for the drop-tracking work
r? `@oli-obk` as you warned me of potential unsoundness
Move format_args!() into AST (and expand it during AST lowering)
Implements https://github.com/rust-lang/compiler-team/issues/541
This moves FormatArgs from rustc_builtin_macros to rustc_ast_lowering. For now, the end result is the same. But this allows for future changes to do smarter things with format_args!(). It also allows Clippy to directly access the ast::FormatArgs, making things a lot easier.
This change turns the format args types into lang items. The builtin macro used to refer to them by their path. After this change, the path is no longer relevant, making it easier to make changes in `core`.
This updates clippy to use the new language items, but this doesn't yet make clippy use the ast::FormatArgs structure that's now available. That should be done after this is merged.
use LocalDefId instead of HirId in trait resolution to simplify
the obligation clause resolution
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Use UnordMap and UnordSet for id collections (DefIdMap, LocalDefIdMap, etc)
This PR changes the `rustc_data_structures::define_id_collections!` macro to use `UnordMap` and `UnordSet` instead of `FxHashMap` and `FxHashSet`. This should account for a large portion of hash-maps being used in places where they can cause trouble.
The changes required are moderate but non-zero:
- In some places the collections are extracted into sorted vecs.
- There are a few instances where for-loops have been changed to extends.
~~Let's see what the performance impact is. With a bit more refactoring, we might be able to get rid of some of the additional sorting -- but the change set is already big enough. Unless there's a performance impact, I'd like to do further changes in subsequent PRs.~~
Performance does not seem to be negatively affected ([perf-run here](https://github.com/rust-lang/rust/pull/106977#issuecomment-1396776699)).
Part of [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
r? `@ghost`
Add `multiple_unsafe_ops_per_block` lint
Adds a lint, which restricts an `unsafe` block to only one unsafe operation.
Closes#10064
---
changelog: New lint: [`multiple_unsafe_ops_per_block`]
[#10206](https://github.com/rust-lang/rust-clippy/pull/10206)
<!-- changelog_checked -->
Fix suggestion in `transmutes_expressible_as_ptr_casts` when the source type is a borrow.
fixes#9894
changelog: `transmutes_expressible_as_ptr_casts`: Fix suggestion when the source type is a borrow.
[needless_return]: Remove all semicolons on suggestion
Closes#10182
Multiple semicolons currently breaks autofix for `needless_return` suggestions. Any semicolons left after removing return means that the return type will always be `()`, and thus fail to compile.
This PR allows `needless_return` to remove multiple semicolons.
The change won't cover the case where there is multiple line yet.
i.e.
```rust
fn needless_return() -> bool {
return true;
;;
}
```
---
changelog: Sugg: [`needless_return`]: Now removes all semicolons on the same line
[#10187](https://github.com/rust-lang/rust-clippy/pull/10187)
<!-- changelog_checked -->
`cast_possible_truncation` Suggest TryFrom when truncation possible
This fixes the last issues from https://github.com/rust-lang/rust-clippy/pull/9664 as the author seems to be inactive. The PR author was sadly kept during the rebase, due to the conflict resolution.
IDK if it's worth it do to a full review, I only added the last commit, everything else remained the same, besides a rebase.
---
changelog: Sugg: [`cast_possible_truncation`]: Now suggests using `try_from` or allowing the lint
[#10038](https://github.com/rust-lang/rust-clippy/pull/10038)
<!-- changelog_checked -->
closes: https://github.com/rust-lang/rust-clippy/issues/9231
Allow implementing `Hash` with derived `PartialEq` (`derive_hash_xor_eq`
This is a common pattern and is totally allowed by the `Hash` trait.
Fixes#2627
changelog: Move: Renamed `derive_hash_xor_eq` to [`derived_hash_with_manual_eq`]
[#10184](https://github.com/rust-lang/rust-clippy/pull/10184)
changelog: Enhancement: [`derived_hash_with_manual_eq`]: Now allows `#[derive(PartialEq)]` with custom `Hash` implementations
[#10184](https://github.com/rust-lang/rust-clippy/pull/10184)
<!-- changelog_checked -->
trim paths in `suspicious_to_owned`
This continues my path trimming spree. I'm not going to add yet another changelog entry, we should have one "trim paths in some applicable lints" entry instead.
---
changelog: none
unused_self: Don't trigger if the method body contains todo!()
If the author is using todo!(), presumably they intend to use self at some point later, so we don't have a good basis to recommend factoring out to an associated function.
Fixes#10117.
---
changelog: Enhancement: [`unused_self`]: No longer lints, if the method body contains a `todo!()` call
[#10166](https://github.com/rust-lang/rust-clippy/pull/10166)
<!-- changelog_checked -->
[#10167] Clarify that the lint only works if x eq. y in a `for` loop.
Reading the documentation for the lint, one could expect that the lint works in all cases that `X == Y`. This is false.
While the lint was updated, the documentation wasn't.
More information about the `N..N` problem in #5689 and #5628
---
Fixes#10167
changelog: [`reversed_empty_ranges`]: Update and clarify documentation
Reading the documentation for the lint, one could expect that the lint works in all cases that `X == Y`. This is false.
While the lint was updated, the documentation wasn't.
More information about the `N..N` problem in #5689 and #5628
trim paths in `box_default`
This might help with #10089, though I have not tested that yet. In any event, it keeps the suggestion short and to the point.
---
changelog: Trim paths in [`box_default`] suggestion
trim paths in `default_trait_access`/`clone_on_copy` suggestions
This should help making the suggestions more palatable. Similar to #10153.
---
changelog: trim paths in [`default_trait_access`]/[`clone_on_copy`] suggestions
If the author is using todo!(), presumably they intend to use self at
some point later, so we don't have a good basis to recommend factoring
out to an associated function.
Fixes#10117.
changelog: Don't trigger [`unused_self`] if the method body contains a `todo!()` call
[`drop_ref`]: don't lint idiomatic in match arm
fixes#10122
As established in issue #9482, it is idiomatic to use a single `drop()` expression in a match arm to achieve a side-effect of a function while discarding its output. This should also apply to cases where the function returns a reference.
The change to the lint's code was less than 1 line, because all the heavy lifting was done in PR #9491.
---
changelog: FP: [`drop_ref`]: No longer lints idiomatic expression in `match` arms
[#10142](https://github.com/rust-lang/rust-clippy/pull/10142)
<!-- changelog_checked -->
Make the iter_kv_map lint handle ref/mut annotations.
For the degenerate (`map(|(k, _)| k)`/`map(|(_, v)| v)`) cases a mut annotation is superfluous and a ref annotation won't compile, so no additional handling is required. For cases where the `map` call must be preserved ref/mut annotations should also be presereved so that the map body continues to work as expected.
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`iter_kv_map`]: handle ref/mut annotations
For the degenerate (`map(|(k, _)| k)`/`map(|(_, v)| v)`) cases a mut annotation is superfluous and a ref annotation won't compile, so no additional handling is required. For cases where the `map` call must be preserved ref/mut annotations should also be presereved so that the map body continues to work as expected.
don't lint field_reassign when field in closure
fixes#10136
This change makes the ContainsName struct visit all interior expressions, which means that ContainsName will return true even if `name` is used in a closure within `expr`.
---
changelog: FP: [`field_reassign_with_default`]: No longer lints cases, where values are initializes from closures capturing struct values
[#10143](https://github.com/rust-lang/rust-clippy/pull/10143)
<!-- changelog_checked -->
chore: fix identation of `if_chain` in `filter_map`
This is a really small fix.
If someone could take a look at it, I would appreciate it🙏
---
changelog: none
<!-- changelog_checked -->
This commit makes the ContainsName struct visit all interior
expressions, which means that ContainsName will return true
even if `name` is used in a closure within `expr`.
Move `mutex_atomic` to `restriction`
By #4295, the general consensus seems to be that `mutex_atomic` is not a useful lint in most cases. If anything, it could be useful as a restriction on code that for whatever reason can't use atomics. Keeping it in `clippy::nursery` is harmful to people attempting to use clippy for soundness.
---
changelog: Moved [`mutex_atomic`] to `restriction`
[#10115](https://github.com/rust-lang/rust-clippy/pull/10115)
<!-- chnagelog_checked -->
Rollup of 9 pull requests
Successful merges:
- #104531 (Provide a better error and a suggestion for `Fn` traits with lifetime params)
- #105899 (`./x doc library --open` opens `std`)
- #106190 (Account for multiple multiline spans with empty padding)
- #106202 (Trim more paths in obligation types)
- #106234 (rustdoc: simplify settings, help, and copy button CSS by not reusing)
- #106236 (docs/test: add docs and a UI test for `E0514` and `E0519`)
- #106259 (Update Clippy)
- #106260 (Fix index out of bounds issues in rustdoc)
- #106263 (Formatter should not try to format non-Rust files)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix incorrect suggestion in `suboptimal_flops`
fixes#10003
There was an error when trying to negate an expression like `x - 1.0`. We used to format it as `-x - 1.0` whereas a proper negation would be `-(x - 1.0)`.
Therefore, we add parentheses around the expression when it is `ExprKind::Binary`.
We also add parentheses around multiply and divide expressions, even though this is not strictly necessary.
changelog: [`suboptimal_flops`]: fix incorrect suggestion caused by an incorrect negation of floating point expressions.
