use short message format in integration test
While checking #12983, bors came upon a cargo change that put "E0463" into the standard error (as part of a test case code snippet), which the integration test picked up to fail the build. Talk about unforeseen consequences.
So this PR just changes the integration test to use short message format in order to not include the code snippets in the output. Hopefully that will fix the problem.
r? `@Alexendoo`
---
changelog: none
resolve `clippy::invalid_paths` on `bool::then`
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: none
Fix incorrect suggestion for `manual_unwrap_or_default`
Fixes#12928.
If this not a "simple" pattern, better not emit the lint.
changelog: Fix incorrect suggestion for `manual_unwrap_or_default`
Add more types to `is_from_proc_macro`
I've been running through going through all the lint implementations to clean them up. I'll be separating out the changes into small PRs to make reviewing easier.
changelog: none
Add myself back to reviewer rotation
Hey 👋
Even though I might have less time than usual, $DAY_JOB soon and working on Cosmographic Software for fun, I think I want to get back in the swing of things here
changelog: none
Lint `manual_unwrap_or` for it let cases
This PR modifies `manual_unwrap_or` to lint for `if let` cases as well. This effort is part of the fixes desired by https://github.com/rust-lang/rust-clippy/issues/12618
changelog:[`manual_unwrap_or`]: Lint for `if let` cases.
Rework `octal_escapes`
Main changes are not doing UTF-8 decoding, noting each occurrence as an individual lint emission, and narrowing the span to point to the escape itself.
changelog: none
Fix ICE in `upper_case_acronyms`
fixes#12284
The logic has been rewritten to avoid allocations. The old version allocated multiple vecs and strings for each identifier. The new logic allocates a single string only when the lint triggers.
This also no longer lints on strings which don't start with an uppercase letter (e.g. `something_FOO`).
changelog: none
Pause assignments to @xFrednet for summer break 🏖️
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.
r? `@ghost`
changelog: none
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
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
