Auto merge of #5788 - Leulz:shadow-unrelated-fix-rhs, r=flip1995
Removing RHS snippet from SHADOW_UNRELATED message.
Fixes #5703
I am not sure if I reinvented the wheel here, but I could not really find a snippet function that did this truncation, so I created the function. Please tell me if there was a more obvious way to do this, I am new here. :smile:
changelog: Truncates multi-line RHS in shadow_unrelated message if it has more than 5 lines.
Auto merge of #5793 - warner:5783-nth-zero-next, r=flip1995
improve advice in iter_nth_zero
fixes #5783
*Please keep the line below*
changelog: For iter_nth_zero, the "use .next()" replacement advice is on the last line of the code snippet, where it is vulnerable to truncation. Display that advice at the beginning instead.
Auto merge of #5737 - Uriopass:unit-for-ord, r=flip1995
Reprise: new lint: Unintentional return of unit from closures expecting Ord
This lint catches cases where the last statement of a closure expecting
an instance of Ord has a trailing semi-colon. It compiles since the
closure ends up return () which also implements Ord but causes
unexpected results in cases such as sort_by_key.
Fixes #5080
Reprise of #5348 where I addressed all the comments there
Matthias Krüger [Mon, 30 Mar 2020 09:02:14 +0000 (11:02 +0200)]
new lint: Returning unit from closures expecting Ord
This lint catches cases where the last statement of a closure expecting
an instance of Ord has a trailing semi-colon. It compiles since the
closure ends up return () which also implements Ord but causes
unexpected results in cases such as sort_by_key.
Brian Warner [Mon, 13 Jul 2020 17:33:25 +0000 (10:33 -0700)]
improve advice in iter_nth_zero
The "use .next()" replacement advice is on the last line of the code snippet,
where it is vulnerable to truncation. Display that advice at the beginning
instead.
Auto merge of #5792 - flip1995:rollup-torc1we, r=flip1995
Rollup of 5 pull requests
Successful merges:
- #5443 (Some accuracy lints for floating point operations)
- #5752 (Move range_minus_one to pedantic)
- #5756 (unnecessary_sort_by: avoid linting if key borrows)
- #5784 (Fix out of bounds access by checking length equality BEFORE accessing by index.)
- #5786 (fix phrase in new_lint issue template)
Philipp Krones [Mon, 13 Jul 2020 13:59:42 +0000 (15:59 +0200)]
Rollup merge of #5752 - chrisduerr:pedantic_ranges, r=flip1995
Move range_minus_one to pedantic
This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see #3307).
While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.
*Please keep the line below*
changelog: move [`range_minus_one`] to pedantic
Auto merge of #5769 - robojumper:match_like_matches_macro, r=phansch
new lint: match_like_matches_macro
Suggests using the `matches!` macro from `std` where appropriate.
`redundant_pattern_matching` has been moved into the `matches` pass to allow suppressing the suggestion where `is_some` and friends are a better replacement.
Christian Duerr [Fri, 26 Jun 2020 15:03:10 +0000 (17:03 +0200)]
Move range_minus_one to pedantic
This moves the range_minus_one lint to the pedantic category, so there
will not be any warnings emitted by default. This should work around
problems where the suggestion is impossible to resolve due to the range
consumer only accepting a specific range implementation, rather than the
`RangeBounds` trait (see #3307).
While it is possible to work around this by extracting the boundary into
a variable, I don't think clippy should encourage people to disable or
work around lints, but instead the lints should be fixable. So hopefully
this will help until a proper implementation checks what the range is
used for.
Auto merge of #74117 - Manishearth:rollup-ds7z0kx, r=Manishearth
Rollup of 14 pull requests
Successful merges:
- #70563 ([rustdoc] Page hash handling)
- #73856 (Edit librustc_lexer top-level docs)
- #73870 (typeck: adding type information to projection)
- #73953 (Audit hidden/short code suggestions)
- #73962 (libstd/net/tcp.rs: #![deny(unsafe_op_in_unsafe_fn)])
- #73969 (mir: mark mir construction temporaries as internal)
- #73974 (Move A|Rc::as_ptr from feature(weak_into_raw) to feature(rc_as_ptr))
- #74067 (rustdoc: Restore underline text decoration on hover for FQN in header)
- #74074 (Fix the return type of Windows' `OpenOptionsExt::security_qos_flags`.)
- #74078 (Always resolve type@primitive as a primitive, not a module)
- #74089 (Add rust-analyzer to the build manifest)
- #74090 (Remove unused RUSTC_DEBUG_ASSERTIONS)
- #74102 (Fix const prop ICE)
- #74112 (Expand abbreviation in core::ffi description)
Rollup merge of #73870 - sexxi-goose:projection-ty, r=nikomatsakis
typeck: adding type information to projection
This commit modifies the Place as follow:
* remove 'ty' from ProjectionKind
* add type information into to Projection
* replace 'ty' in Place with 'base_ty'
* introduce 'ty()' in `Place` to return the final type of the `Place`
* introduce `ty_before_projection()` in `Place` to return the type of
a `Place` before i'th projection is applied
Auto merge of #5301 - JarredAllen:option_if_let_else, r=flip1995
Suggest `Option::map_or`(_else) for `if let Some { y } else { x }`
Fixes #5203
There are two issues with this code that I have noticed:
- Use of `Option::map_or` causes it to always evaluate the code in the else block. If that block is computationally expensive or if it updates some state (such as getting the next value from an iterator), then this change would cause the code to behave differently. In either of those circumstances, it should suggest Option::map_or_else, which takes both cases as a closure and runs one. However, I don't know how to check if the expression would change some state, so I left the lint's applicability as MaybeIncorrect.
- There are lints which can trigger on specific sub-cases of this lint (`if_let_some_result`, `question_mark`, and `while_let_loop`) and suggest different changes (usually better ones because they're more specific). Is this acceptable for clippy to give multiple suggestions, or should I have the code check if those other lints trigger and then not trigger this lint if they do?
Auto merge of #4841 - phaylon:pattern-type-mismatch, r=flip1995
Added restriction lint: pattern-type-mismatch
changelog: Added a new restriction lint `pattern-type-mismatch`. This lint is especially helpful for beginners learning about the magic behind pattern matching. (This explanation might be worth to include in the next changelog.)
Auto merge of #5761 - ThibsG:TypeRepetitionThreshold, r=flip1995
Improvements for `type_repetition_in_bounds` lint
Some improvements for `type_repetition_in_bounds`:
- add a configurable threshold to trigger the lint (#4380). The lint won't trigger anymore if there are more bounds (strictly) than `conf.max_trait_bounds` on this type.
- take generic args into account over bounded type (#4323)
- don't lint for predicates generated in macros (#4326)