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 `...` in multline code-skips in suggestions
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was inconsistent with what we do in every other case *and* off-center.
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`
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was consistent with what we do in every other case.
This removes the ICE codepaths for `f16` and `f128` in Clippy.
`rustc_apfloat` is used as a dependency for the parsing of these types,
since their `FromStr` implementation will not be available in the
standard library for a while.
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
