I'm only removing myself from the assignment roulette as I want to allow `r? xFrednet` for `gh-pages` and other updates. So feel free to still `r?` me.
Add lint `manual_inspect`
fixes#12250
A great example of a lint that sounds super simple, but has a pile of edge cases.
----
changelog: Add lint `manual_inspect`
* Delay the parsing of the use node
* Mark when the `SyntaxContext` changes rather than return `None`
* Return a default value if the HIR tree is broken rather than `None`
Add field_scoped_visibility_modifiers lint
changelog: [`field_scoped_visibility_modifiers`]: Add a lint which checks for struct fields using Restricted (not inherited, not public) visibility modifiers.
Merge lintcheck popular-crates bin as a subcommand
Also rewrites it to use `ureq` to drop some heavy dependencies as `crates_io_api` brings in `reqwest`
r? `@xFrednet`
changelog: none
Avoid emitting `assigning_clones` when cloned data borrows from the place to clone into
Fixes#12444Fixes#12460Fixes#12749Fixes#12757Fixes#12929
I think the documentation for the function should describe what- and how this is fixing the issues well.
It avoids emitting a warning when the data being cloned borrows from the place to clone into, which is information that we can get from `PossibleBorrowerMap`. Unfortunately, it is a tiny bit tedious to match on the MIR like that and I'm not sure if this is possibly relying a bit too much on the exact MIR lowering for assignments.
Things left to do:
- [x] Handle place projections (or verify that they work as expected)
- [x] Handle non-`Drop` types
changelog: [`assigning_clones`]: avoid warning when the suggestion would lead to a borrow-check error
Fix doc nits
Clippy is wonderful, and reading its lints is a great way to learn about Rust. While doing this, I noticed a few little copyedits, such as adding trailing periods to sentences, or tweaking wording very slightly to improve its readability. I hope you will accept these suggestions as an act of love for the project, with my thanks for all the maintainers' hard work.
changelog: Docs [ mut_range_bound ]: fix doc nits
changelog: Docs [ needless_for_each ]: fix doc nits
changelog: Docs [ arc_with_non_send_sync ]: fix doc nits
changelog: Docs [ allow_attributes ]: fix doc nits
changelog: Docs [ allow_attributes_without_reason ]: fix doc nits
When both `std::` and `core::` items are available, only suggest the
`std::` ones. We ensure that in `no_std` crates we suggest `core::`
items.
Ensure that the list of items suggested to be imported are always in the
order of local crate items, `std`/`core` items and finally foreign crate
items.
Tweak wording of import suggestion: if there are multiple items but they
are all of the same kind, we use the kind name and not the generic "items".
Fix#83564.
Let `qualify_min_const_fn` deal with drop terminators
Fixes#12677
The `method_accepts_droppable` check that was there seemed overly conservative.
> Returns true if any of the method parameters is a type that implements `Drop`.
> The method can't be made const then, because `drop` can't be const-evaluated.
Accepting parameters that implement `Drop` should still be fine as long as the parameter isn't actually dropped, as is the case in the linked issue where the droppable is moved into the return place. This more accurate analysis ("is there a `drop` terminator") is already done by `qualify_min_const_fn` [here](f5e250180c/clippy_utils/src/qualify_min_const_fn.rs (L298)), so I don't think this additional check is really necessary?
Fixing the other, second case in the linked issue was only slightly more involved, since `Vec::new()` is a function call that has the ability to panic, so there must be a `drop()` terminator for cleanup, however we should be able to freely ignore that. [Const checking ignores cleanup blocks](https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/transform/check_consts/check.rs#L382-L388), so we should, too?
r? `@Jarcho`
----
changelog: [`missing_const_for_fn`]: continue linting on fns with parameters implementing `Drop` if they're not actually dropped
Add lint to check manual pattern char comparison
This PR adds a new lint asked in https://github.com/rust-lang/rust-clippy/issues/12490
This lint catches manual char comparison in pattern of string functions and propose to use `char` or array of `char` instead.
As it's my first contribution i'm not feeling very safe about not matching too much or missing some cases.
Thanks in advance for taking time to review and propose feedback !
changelog: new lint [`manual_pattern_char_comparison`]
Don't lint indexing_slicing lints on proc macros
This pr fixes https://github.com/rust-lang/rust-clippy/issues/12824
Even though the issue mentions the indexing case only, it was easy to apply the fix to the slicing case as well.
changelog: [`out_of_bounds_indexing`, `indexing_slicing`]: Don't lint on procedural macros.
Handle single chars with `to_string()` for `single_char_add_str`
Add support for single chars / literals with `to_string()` call for `push_str()` and `insert_str()`.
changelog: [`single_char_add_str`]: handle single chars with `to_string()` call
Closes#12775
Normalize type aliases when checking significant drops.
fixes#10750
No test as I'm not sure exactly how the type alias caused a stack overflow here. Also removes an unnecessary `HashSet`.
changelog: none
- remove now dead code in ASSERTIONS_ON_CONSTANTS
cc #11966
- Partially revert "ignore `assertions-on-constants` in const contexts"
This reverts commit c7074de420a2192fb40d3f2194a20dd0d1b65cc6.
