Reassign default private
changelog: fix field_reassign_with_default false positive
* Fix#6344
* Fix assumption that `field: Default::default()` is the same as `..Default::default()`
* Cleanup some redundant logic
Added from_over_into lint
Closes#6456
Added a lint that searches for implementations of `Into<..>` and suggests to implement `From<..>` instead, as it comes with a default implementation of `Into`. Category: style.
changelog: added `from_over_into` lint
Lint also in trait def for `wrong_self_convention`
Extends `wrong_self_convention` to lint also in trait definition.
By the way, I think the `wrong_pub_self_convention` [example](dd826b4626/clippy_lints/src/methods/mod.rs (L197)) is misleading.
On [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=32615ab3f6009e7e42cc3754be0ca17f), it fires `wrong_self_convention`, so the example (or the lint maybe?) needs to be reworked.
The difference with `wrong_self_convention` [example](dd826b4626/clippy_lints/src/methods/mod.rs (L172)) is mainly the `pub` keyword on the method `as_str`, but the lint doesn't use the function visibility as condition to choose which lint to fire (in fact it uses the visibility of the impl item).
fixes: #6307
changelog: Lint `wrong_self_convention` lint in trait def also
needless_doctest_main: handle correctly parse errors
Before this change, finding an error when parsing a doctest would make Clippy exit without emitting an error. Now we properly catch a fatal error and ignore it.
Also, if a doctest specifies an edition in the info line, it will be used when parsing it.
changelog: needless_doctest_main: handle correctly parse errors
Fixes#6022
Move binder for dyn to each list item
This essentially changes `ty::Binder<&'tcx List<ExistentialTraitRef>>` to `&'tcx List<ty::Binder<ExistentialTraitRef>>`.
This is a first step in moving the `dyn Trait` representation closer to Chalk, which we've talked about in `@rust-lang/wg-traits.`
r? `@nikomatsakis`
Implement if-let match guards
Implements rust-lang/rfcs#2294 (tracking issue: #51114).
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` ❤️ for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
Fixing a false positive for the `match_single_binding` lint #5552
This is a fix for a false positive in the `match_single_binding` lint when using `#[cfg()]` on a branch. It is sadly a bit hacky but maybe the best solution as rust removes the other branch from the AST before we can even validate it. This fix looks at the code snippet itself and returns if it includes another thick arrow `=>` besides the one matching arm we found. This can again cause false negatives if someone has the following code:
```rust
match x {
// => <-- Causes a false negative
_ => 1,
}
```
I thought about making the code more complex and maybe validating against other things like the `#[cfg()]` macro but I believe that this is the best solution. This has basically switched the issue from a false positive to a false negative in a very specific case.
I'm happy to make some changes if you have any suggestions 🙃.
---
Fixes#5552
changelog: Fixed a false positive in the `match_single_binding` lint with `#[cfg()]` macro
Add MSRV to more lints specified in #6097
add MSRV to more lints specified in #6097
add instructions for adding msrv in other lints
update tests
- [x] `redundant_field_names` requires Rust 1.17 due to suggest feature stablized in that version.
- [x] `redundant_static_lifetimes` requires Rust 1.17 due to suggest feature stablized in that version.
- [x] `filter_map_next` requires Rust 1.30 due to suggest `Iterator::find_map`.
- [x] `checked_conversions` requires Rust 1.34 due to suggest `TryFrom`.
- [x] `match_like_matches_macro` requires Rust 1.42 due to suggest `matches!`. Addressed in #6201
- [x] `manual_strip` requires Rust 1.45 due to suggest `str::{strip_prefix, strip_suffix}`. Addressed in #6201
- [x] `option_as_ref_deref` requires Rust 1.40 due to suggest `Option::{as_deref, as_deref_mut}`. Addressed in #6201
- [x] `manual_non_exhaustive` requires Rust 1.40 due to suggest `#[non_exhaustive]`. Addressed in #6201
- [x] `manual_range_contains` requires Rust 1.35 due to suggest `Range*::contains`.
- [x] `use_self` requires Rust 1.37 due to suggest `Self::Variant on enum`.
- [x] `mem_replace_with_default` requires Rust 1.40 due to suggest `mem::take`.
- [x] `map_unwrap_or` requires Rust 1.41 due to suggest `Result::{map_or, map_or_else}`.
- [x] `missing_const_for_fn` requires Rust 1.46 due to `match/if/loop in const fn` needs that version.
changelog: Add MSRV config to more lints. ^This is now the complete list, AFAWK
Add lint print_stderr
Resolves#6348
Almost identical to print_stdout, this lint applies to the `eprintln!` and `eprint!` macros rather than `println!` and `print!`.
changelog: Add new lint [`print_stderr`]. [`println_empty_string`] and [`print_with_newline`] now apply to `eprint!()` and `eprintln!()` respectively.
Added a lint-fraction-readability flag to the configuration
This adds an option to disable the `unreadable_literal` lint for floats with a longer fraction. This allows users to write `0.100200300` without getting a warning. Fixes#4176
I have some open questions about this PR:
1. I've named the option `lint-fraction-readability` is this a good name or should I rename it to something else?
2. What should the default configuration value be?
* The current default value is `true` as this was also the previous default.
3. Do I have to document this new option somewhere else or will it be extracted from the code comment?
4. The current fix option will also rewrite the fraction if the integer part violates the `unreadable_literal` lint it would otherwise also trigger the `inconsistent_digit_grouping` lint. Is this also okay?
* `1.100200300` will be unaffected by the fix function
* `100200300.100200300` will be effected and fixed to `100_200_300.100_200_300`
---
The project needed some getting used to but I'm happy with the result. A big thank you to `@flip1995` for giving me some pointers for this implementation and to everyone for the great introduction documentation!
---
changelog: Added the `unreadable-literal-lint-fractions` configuration to disable the `unreadable_literal` lint for fractions
Moved map_err_ignore to restriction and updated help message
This MR moves map_err_ignore lint from `pedantic` to the `restriction` category of lints and updates the help message to give the user an option to ignore the lint by naming the closure variable e.g. `.map_err(|_ignored| ...`
---
changelog: move map_err_ignore to restriction category
Specifically ptr::{sub, wrapping_sub, add, wrapping_add, offset, wrapping_offset} and slice::{from_raw_parts, from_raw_parts_mut}
The lint now also looks for size_of calls through casts (Since offset takes an isize)
Also fix review comments:
- Use const arrays and iterate them for the method/function names
- merge 2 if_chain's into one using a rest pattern
- remove unnecessary unsafe block in test
And make the lint only point to the count expression instead of the entire function call
Add Collapsible match lint
changelog: Add collapsible_match lint
Closes#1252Closes#2521
This lint finds nested `match` or `if let` patterns that can be squashed together. It is designed to be very conservative to only find cases where merging the patterns would most likely reduce cognitive complexity.
Example:
```rust
match result {
Ok(opt) => match opt {
Some(x) => x,
_ => return,
}
_ => return,
}
```
to
```rust
match result {
Ok(Some(x)) => x,
_ => return,
}
```
These criteria must be met for the lint to fire:
* The inner match has exactly 2 branches.
* Both the outer and inner match have a "wild" branch like `_ => ..`. There is a special case for `None => ..` to also be considered "wild-like".
* The contents of the wild branches are identical.
* The binding which "links" the matches is never used elsewhere.
Thanks to the hir, `if let`'s are easily included with this lint since they are desugared into equivalent `match`'es.
I think this would fit into the style category, but I would also understand changing it to pedantic.
Enhance `redundant_pattern_matching` to also lint on `std::net::IpAddr`
Follow-up to #6339
r? `@ebroto`
(note: also contains a small cleanup of the other ui tests)
changelog: Enhance [`redundant_pattern_matching`] to also lint on `std::net::IpAddr`
Added known problem to comparison_chain docs
changelog: Added documentation to comparison_chain that explains a possible performance penalty, according to issue #5354
This is my first PR, I hope everything has been done correctly.
Fixes#5354
Add suspicious_operation_groupings lint
This is my (<del> currently WIP </del>) attempt to close#6039.
changelog: Added `suspicious_operation_groupings` lint.
run `cargo dev new_lint --category correctness --name suspicious_chained_operators --pass early`
add (currently failing) tests for suspicious_chained_operators
add some tests to answer a question that came up during implementation
write usage code for functions we'll need to find or create
Complete left-right tracking TODO
get it compiling with several `todo!` invocations.
refactor to a set of incomplete functions that don't expect to be able to edit a `Span`
create placeholder for `suggestion_with_swapped_ident` function and correct some comments
add `inside_larger_boolean_expression` test
fill out `get_ident` and `suggestion_with_swapped_ident`
Implementi the `IdentIter`
start on implementing the `IdentIter`
handle the `ExprKind::Path` case in `IdentIter`
on second thought, make the iterator type dynamic so we don't need an explicit type for each one we will need
handle `ExprKind::MacCall` in `IdentIter`
Try handling `box x` expressions
restructure `IdentIter`
set `self.done` when returning `None`
Handle `ExprKind::Array`
reduce duplication with a macro that we expect to use several more times
handle ExprKind::Call
add `new_p` convenience method
handle `MethodCall`
handle `Tup` and `Binary`
handle `Unary`
simplify by not returning an additional `Expr` from the `IdentIter`
add cross product test against false positives
rename suspicious_chained_operators to suspicious_operation_groupings within files
For the record, the exact commands run were:
find . -type f -name "*.md" -exec sed -i 's/suspicious_chained_operators/suspicious_operation_groupings/g' {} +
find . -type f -name "*.rs" -exec sed -i 's/suspicious_chained_operators/suspicious_operation_groupings/g' {} +
find . -type f -name "*.rs" -exec sed -i 's/SUSPICIOUS_CHAINED_OPERATORS/SUSPICIOUS_OPERATION_GROUPINGS/g' {} +
find . -type f -name "*.rs" -exec sed -i 's/SuspiciousChainedOperators/SuspiciousOperationGroupings/g' {} +
Also:
rename file to match module name
rename test file to match lint name
start implementing `IdentDifference` creation
add `IdentIter` utility
use `ident_iter::IdentIter`
fix bug in `suggestion_with_swapped_ident`
add `inside_if_statements` test
implement `Add` `todo`s
register `SuspiciousOperationGroupings` lint pass
fill in `chained_binops`, and fill in a stopgap version of `ident_difference_expr`, but then notice that the lint does not seem to ever be run in the tests
run `cargo dev update_lints` and not that the `suspicious_operation_groupings` lint still does not seem to be run
fix base index incrementing bug
fix paired_identifiers bug, and remove ident from `Single`
change help prefix and note our first successful lint messages!
add odd_number_of_pairs test
get the `non_boolean_operators` test passing, with two copies of the error message
extract `is_useless_with_eq_exprs` so we can know when `eq_op` will already handle something
add `not_caught_by_eq_op` tests since `s1.b * s1.b` was (reasonably) not caught by `eq_op`
cover the case where the change should be made on either side of the expression with `not_caught_by_eq_op` tests
produce the expected suggestion on the `not_caught_by_eq_op_middle_change_left` test
confirm that the previous tests still pass and update references
fix early continue bug and get `not_caught_by_eq_op_middle_change_right` passing
note that `not_caught_by_eq_op_start` already passes
fix bugs based on misunderstanding of what `Iterator::skip` does, and note that `not_caught_by_eq_op_end` now passes
add several parens tests and make some of them pass
handle parens inside `chained_binops_helper` and note that this makes several tests pass
get `inside_larger_boolean_expression_with_unsorted_ops` test passing by extracting out `check_same_op_binops` function
also run `cargo dev fmt`
note that `inside_function_call` already passes
add another `if_statement` test
remove the matching op requirement, making `inside_larger_boolean_expression_with_unsorted_ops` pass
prevent non-change suggestions from being emitted
get the `Nested` tests passing, and remove apparently false note about eq_op
add a test to justify comment in `ident_difference_expr_with_base_location` but find that the failure mode seems different than expected
complete `todo` making `do_not_give_bad_suggestions_for_this_unusual_expr` pass and add some more tests that already pass
add test to `eq_op`
note that `inside_fn_with_similar_expression` already passes
fix `inside_an_if_statement` and note that it already passes
attempt to implement if statement extraction and notice that we don't seem to handle unary ops correctly
add `maximum_unary_minus_right_tree` test and make it pass
add two tests and note one of them passes
filter out unary operations in several places, and find that the issue seems to be that we don't currently recognize the error in `multiple_comparison_types_and_unary_minus` even so.
remove filtering that was causing bad suggestions
remove tests that were deemed too much for now
run `cargo dev fmt`
correct eq_op post-merge
fill out the description and delete debugging code
run `cargo dev update_lints`
update eq_op references
add parens to work around rustfmt issue #3666 and run rustfmt
https://github.com/rust-lang/rustfmt/issues/3666#issuecomment-714612257
update references after formatting
fix dogfood issues
fix multi-cursor edit
fix missed dogfood error
fix more dogfood pedantic issues, including function length
even more nesting
insert hidden definition of Vec3 so docs compile
add spaces to second struct def
reword test description comment
Co-authored-by: llogiq <bogusandre@gmail.com>
add local `use BinOpKind::*;`
Apply suggestions from code review
Co-authored-by: llogiq <bogusandre@gmail.com>
switch `SUSPICIOUS_OPERATION_GROUPINGS` to a style lint
run `cargo dev update_lints`
put both usages of `op_types` in the same closure to satisfy `borrowck`
fix compile error
rustc_ast currently has a few dependencies on rustc_lexer. Ideally, an AST
would not have any dependency its lexer, for minimizing unnecessarily
design-time dependencies. Breaking this dependency would also have practical
benefits, since modifying rustc_lexer would not trigger a rebuild of rustc_ast.
This commit does not remove the rustc_ast --> rustc_lexer dependency,
but it does remove one of the sources of this dependency, which is the
code that handles fuzzy matching between symbol names for making suggestions
in diagnostics. Since that code depends only on Symbol, it is easy to move
it to rustc_span. It might even be best to move it to a separate crate,
since other tools such as Cargo use the same algorithm, and have simply
contain a duplicate of the code.
This changes the signature of find_best_match_for_name so that it is no
longer generic over its input. I checked the optimized binaries, and this
function was duplicated at nearly every call site, because most call sites
used short-lived iterator chains, generic over Map and such. But there's
no good reason for a function like this to be generic, since all it does
is immediately convert the generic input (the Iterator impl) to a concrete
Vec<Symbol>. This has all of the costs of generics (duplicated method bodies)
with no benefit.
Changing find_best_match_for_name to be non-generic removed about 10KB of
code from the optimized binary. I know it's a drop in the bucket, but we have
to start reducing binary size, and beginning to tame over-use of generics
is part of that.
Change `redundant_pattern_matching` to also lint `std::task::Poll`
`reduntant_pattern_matching` currently lints pattern matching on `Option` and `Result` where the `is_variant` utility methods could be used instead: `is_some`, `is_none`, `is_ok`, `is_err`. This PR extends this behaviour to `std::task::Poll`, suggesting the methods `is_pending` and `is_ready`.
Motivation: The current description of `redundant_pattern_matching` mentions
> It's more concise and clear to just use the proper utility function
which in my mind applies to `Poll` as well.
changelog: Enhance [`redundant_pattern_matching`] to also lint on `std::task::Poll`
Drop support for all cloudabi targets
`cloudabi` is a tier-3 target, and [it is no longer being maintained upstream][no].
This PR drops supports for cloudabi targets. Those targets are:
* aarch64-unknown-cloudabi
* armv7-unknown-cloudabi
* i686-unknown-cloudabi
* x86_64-unknown-cloudabi
Since this drops supports for a target, I'd like somebody to tag `relnotes` label to this PR.
Some other issues:
* The tidy exception for `cloudabi` crate is still remained because
* `parking_lot v0.9.0` and `parking_lot v0.10.2` depends on `cloudabi v0.0.3`.
* `parking_lot v0.11.0` depends on `cloudabi v0.1.0`.
[no]: https://github.com/NuxiNL/cloudabi#note-this-project-is-unmaintained
Fix handling of panic calls
This should make Clippy more resilient and will unblock #78343.
This PR is made against rust-lang/rust to avoid the need for a subtree
sync at ``@flip1995's`` suggestion in rust-lang/rust-clippy#6310.
r? ``@flip1995``
cc ``@m-ou-se``
This should make Clippy more resilient and will unblock #78343.
This PR is made against rust-lang/rust to avoid the need for a subtree
sync at @flip1995's suggestion in rust-lang/rust-clippy#6310.
Introduce `TypeVisitor::BreakTy`
Implements MCP rust-lang/compiler-team#383.
r? `@ghost`
cc `@lcnr` `@oli-obk`
~~Blocked on FCP in rust-lang/compiler-team#383.~~
Add a case to `lint_search_is_some` to handle searching strings
Fixes: #6010
This adds a lint which recommends using `contains()` instead of `find()` followed by `is_some()` on strings as suggested in #6010.
This was added as an additional case to
5af88e3c2d/clippy_lints/src/methods/mod.rs (L3037)
I would really appreciate any comments/suggestions for my code!
changelog: Added case to `lint_search_is_some` to handle searching strings
Implement destructuring assignment for structs and slices
This is the second step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the second part of #71156, which was split up to allow for easier review.
Note that the first PR (#78748) is not merged yet, so it is included as the first commit in this one. I thought this would allow the review to start earlier because I have some time this weekend to respond to reviews. If ``@petrochenkov`` prefers to wait until the first PR is merged, I totally understand, of course.
This PR implements destructuring assignment for (tuple) structs and slices. In order to do this, the following *parser change* was necessary: struct expressions are not required to have a base expression, i.e. `Struct { a: 1, .. }` becomes legal (in order to act like a struct pattern).
Unfortunately, this PR slightly regresses the diagnostics implemented in #77283. However, it is only a missing help message in `src/test/ui/issues/issue-77218.rs`. Other instances of this diagnostic are not affected. Since I don't exactly understand how this help message works and how to fix it yet, I was hoping it's OK to regress this temporarily and fix it in a follow-up PR.
Thanks to ``@varkor`` who helped with the implementation, particularly around the struct rest changes.
r? ``@petrochenkov``
Do not collect tokens for doc comments
Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).
(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)
r? `@Aaron1011`
instead of `find()` follows by `is_some()` on strings
Update clippy_lints/src/find_is_some_on_strs.rs
Co-authored-by: Takayuki Nakata <f.seasons017@gmail.com>
Update clippy_lints/src/methods/mod.rs
Co-authored-by: Philipp Krones <hello@philkrones.com>
Add `let_underscore_drop`
This line generalizes `let_underscore_lock` (#5101) to warn about any initializer expression that implements `Drop`.
So, for example, the following would generate a warning:
```rust
struct Droppable;
impl Drop for Droppable {
fn drop(&mut self) {}
}
let _ = Droppable;
```
I tried to preserve the original `let_underscore_lock` functionality in the sense that the warning generated for
```rust
let _ = mutex.lock();
```
should be unchanged.
*Please keep the line below*
changelog: Add lint [`let_underscore_drop`]
rustc_ast: Do not panic by default when visiting macro calls
Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them.
The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
Fix bad suggestions for `deref_addrof` and `try_err` lints
Fix bad suggestions when in macro expansion for `deref_addrof` and `try_err` lints.
Fixes: #6234Fixes: #6242Fixes: #6237
changelog: none
r? `@llogiq`
Fix example used in cargo_common_metadata
The previous example used in `cargo_common_metadata` included an authors field, even though the comment says it doesn't. And thus doesn't actually demonstrate an example of how the lint fails.
This removes that authors field from the _bad_ example and suggest to fix the _bad_ example by adding the authors field
changelog: Fix example used in `cargo_common_metadata`
We skip the lint if the `loop {}` is in the `#[panic_handler]` as the
main recommendation we give is to panic, which obviously isn't
possible in a panic handler.
Signed-off-by: Joe Richey <joerichey@google.com>
Check when `from_utf8` is called from sliced byte array from string
---
*Please keep the line below*
changelog: Fix#5487: Add linter to check when `from_utf8` is called from sliced byte array from string.
"Respect" enums in `interior_mutable_const`
fixes#3962fixes#3825
Hello,
It might not be a good idea to submit another relatively large PR while I have an opened PR; but, I've finished this anyway. This may be able to wait for months.
Note: the code uses the MIR interpreter, which the author of #3962 thought unlikely to be a solution. This might be over-engineering; but, I think it's important to be able to work with the 'http' crate (#3825). (And, I don't want to write a MIR visitor)
---
changelog: fix a false positive in two `interior_mutable_const` lints where a constant with enums gets linted
even if it uses a clearly unfrozen variant
Provide diagnostic suggestion in ExprUseVisitor Delegate
The [Delegate trait](981346fc07/compiler/rustc_typeck/src/expr_use_visitor.rs (L28-L38)) currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.
Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.
Eg:
```
let arr : [String; 5];
let [a, ...] = arr;
^^^ E1 ^^^ = ^^E2^^
```
Here `arr` is moved because of the binding created E1. However, when we
point to E1 in diagnostics with the message `arr` was moved, it can be
confusing. Rather we would like to report E2 to the user.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
r? `@ghost`
Add lint for 'field_reassign_with_default` #568
changelog: Add lint for field_reassign_with_default that checks if mutable object + field modification is used to edit a binding initialized with Default::default() instead of struct constructor.
Fixes#568
Notes:
- Checks for reassignment of one or more fields of a binding initialized with Default::default().
- Implemented using EarlyLintPass, might be future proofed better with LateLintPass.
- Does not trigger if Default::default() is used via another type implementing Default.
- This is a re-open of [PR#4761](https://github.com/rust-lang/rust-clippy/pull/4761), but I couldn't figure out how to re-open that one so here's a new one with the requested changes :S
Use const sym where possible
I ran a regex search and replace to use const `sym` values where possible. This should give some performance boost by avoiding string interning at runtime.
Con: It is not as consistent as always using `sym!`.
I also changed an internal lint to suggest using `sym::{}`, making an assumption that this will always work for diagnostic items.
changelog: none
Add lint 'ref_option_ref' #1377
This lint checks for usage of `&Option<&T>` which can be simplified as `Option<&T>` as suggested in #1377.
This WIP PR is here to get feedback on the lint as there's more cases to be handled:
* statics/consts,
* associated types,
* type alias,
* function/method parameter/return,
* ADT definitions (struct/tuple struct fields, enum variants)
changelog: Add 'ref_option_ref' lint
Add lint: from_iter_instead_of_collect
Fixes#5679
This implements lint for `::from_iter()` from #5679 not the general issue (`std::ops::Add::add`, etc.).
This lint checks if expression is function call with `from_iter` name and if it's implementation of the `std::iter::FromIterator` trait.
changelog: Introduce from_iter_instead_of_collect lint
single_char_insert_str: lint using insert_str() on single-char literals and suggest insert()
Fixes#6026
changelog: add single_char_insert_str lint which lints using string.insert_str() with single char literals and suggests string.insert() with a char
The [Delegate
trait](981346fc07/compiler/rustc_typeck/src/expr_use_visitor.rs (L28-L38))
currently use `PlaceWithHirId` which is composed of Hir `Place` and the
corresponding expression id.
Even though this is an accurate way of expressing how a Place is used,
it can cause confusion during diagnostics.
Eg:
```
let arr : [String; 5];
let [a, ...] = arr;
^^^ E1 ^^^ = ^^E2^^
```
Here `arr` is moved because of the binding created E1. However, when we
point to E1 in diagnostics with the message `arr` was moved, it can be
confusing. Rather we would like to report E2 to the user.
Closes: https://github.com/rust-lang/project-rfc-2229/issues/20
Implement rustc side of report-future-incompat
cc https://github.com/rust-lang/rust/issues/71249
This is an alternative to `@pnkfelix's` initial implementation in https://github.com/pnkfelix/rust/commits/prototype-rustc-side-of-report-future-incompat (mainly because I started working before seeing that branch 😄 ).
My approach outputs the entire original `Diagnostic`, in a way that is compatible with incremental compilation. This is not yet integrated with compiletest, but can be used manually by passing `-Z emit-future-incompat-report` to `rustc`.
Several changes are made to support this feature:
* The `librustc_session/lint` module is moved to a new crate `librustc_lint_defs` (name bikesheddable). This allows accessing lint definitions from `librustc_errors`.
* The `Lint` struct is extended with an `Option<FutureBreakage>`. When present, it indicates that we should display a lint in the future-compat report. `FutureBreakage` contains additional information that we may want to display in the report (currently, a `date` field indicating when the crate will stop compiling).
* A new variant `rustc_error::Level::Allow` is added. This is used when constructing a diagnostic for a future-breakage lint that is marked as allowed (via `#[allow]` or `--cap-lints`). This allows us to capture any future-breakage diagnostics in one place, while still discarding them before they are passed to the `Emitter`.
* `DiagnosticId::Lint` is extended with a `has_future_breakage` field, indicating whether or not the `Lint` has future breakage information (and should therefore show up in the report).
* `Session` is given access to the `LintStore` via a new `SessionLintStore` trait (since `librustc_session` cannot directly reference `LintStore` without a cyclic dependency). We use this to turn a string `DiagnosticId::Lint` back into a `Lint`, to retrieve the `FutureBreakage` data.
Currently, `FutureBreakage.date` is always set to `None`. However, this could potentially be interpreted by Cargo in the future.
I've enabled the future-breakage report for the `ARRAY_INTO_ITER` lint, which can be used to test out this PR. The intent is to use the field to allow Cargo to determine the date of future breakage (as described in [RFC 2834](https://github.com/rust-lang/rfcs/blob/master/text/2834-cargo-report-future-incompat.md)) without needing to parse the diagnostic itself.
cc `@pnkfelix`
- Implement `field_reassign_with_default` as a `LateLintPass`
- Avoid triggering `default_trait_access` on a span already linted by
`field_reassigned_with_default`
- Merge `default_trait_access` and `field_reassign_with_default` into
`Default`
- Co-authored-by: Eduardo Broto <ebroto@tutanota.com>
- Fixes#568
Update the existing arithmetic lint
re: #6209
Updates the lint to not the error message if RHS of binary operation `/` of `%` is a literal/constant that is not `0` or `-1`, as suggested [here](https://github.com/rust-lang/rust-clippy/issues/6209#issuecomment-715624354)
changelog: Expand [`integer_arithmetic`] to work with RHS literals and constants
fix the error-causing suggestion of 'borrowed_box'
Fixes#3128
Fix the suggestion of 'borrowed_box', which causes a syntax error because it misses necessary parentheses.
---
changelog: Fix the error-causing suggestion of 'borrowed_box'
Add lint for comparing to empty slices instead of using .is_empty()
Hey first time making a clippy lint
I added the implementation of the lint the `len_zero` since it shared a lot of the code, I would otherwise have to rewrite. Just tell me if the lint should use it's own file instead
changelog: Add lint for comparing to empty slices
Fixes#6217
Lint items after statements in local macro expansions
The items_after_statements lint was skipping all expansions. Instead
we should still lint local macros.
Fixes#578
---
*Please keep the line below*
changelog: The items_after_statements now applies to local macro expansions
No lint in macro for `toplevel_ref_arg`
Do not lint when the span is from a macro.
Question: shouldn't we extend this for external macros also ?
Fixes: #5849
changelog: none
Hex bin digit grouping
This revives and updates an old pr (#3391) for the current API.
Closes#2538.
---
*Please keep the line below*
changelog: Add [`unusual_byte_groupings`] lint.
Remove redundant `expect_local()` call
The field `owner` of `HirId` is `LocalDefId` and `hir_id.owner.to_def_id().expect_local()` is redundant. I wonder they were introduced in some rustups.
changelog: none
No lint with `cfg!` and fix sugg for macro in `needless_bool` lint
Don't lint if `cfg!` macro is one of the operand.
Fix suggestion when the span originated from a macro, using `hir_with_macro_callsite`.
Fixes: #3973
changelog: none
New lint: manual-range-contains
This fixes#1110, at least for the contains-suggesting part.
- \[x] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`
---
changelog: new lint: manual-range-contains
Add lint for `&mut Mutex::lock`
Fixes#1765
changelog: Add lint [`mut_mutex_lock`] for `&mut Mutex::lock` and suggests using `&mut Mutex::get_mut` instead.
