bors [Mon, 8 Aug 2022 15:20:24 +0000 (15:20 +0000)]
Auto merge of #9126 - Jarcho:auto_deref_sugg, r=Manishearth
`explicit_auto_deref` changes
fixes #9123
fixes #9109
fixes #9143
fixes #9101
This avoid suggesting code which hits a rustc bug. Basically `&{x}` won't use auto-deref if the target type is `Sized`.
changelog: Don't suggest using auto deref for block expressions when the target type is `Sized`
changelog: Include the borrow in the suggestion for `explicit_auto_deref`
changelog: Don't lint `explicit_auto_deref` on `dyn Trait` return
changelog: Don't lint `explicit_auto_deref` when other adjustments are required
changelog: Lint `explicit_auto_deref` in implicit return positions for closures
bors [Mon, 8 Aug 2022 09:27:33 +0000 (09:27 +0000)]
Auto merge of #8694 - Jarcho:check_proc_macro, r=xFrednet
More proc-macro detection
fixes #6514
fixes #8683
fixes #6858
fixes #6594
This is a more general way of checking if an expression comes from a macro and could be trivially applied to other lints. Ideally this would be fixed in rustc's proc-macro api, but I don't see that happening any time soon.
changelog: FPs: [`unit_arg`] [`default_trait_access`] [`missing_docs_in_private_items`]: No longer trigger in code generated from proc-macros.
bors [Mon, 8 Aug 2022 08:28:06 +0000 (08:28 +0000)]
Auto merge of #9302 - Jarcho:sig_drop_nursery, r=flip1995
Move `significant_drop_in_scrutinee` into `nursey`
The current suggestion of extending the lifetime of every sub-expression is not great and doesn't fix the error given in the lint's example, though it does make the potential deadlock easier to see, but it can also cause it's own issues by delaying the drop of the lock guard.
e.g.
```rust
match x.lock().foo {
..
}
// some stuff
let y = x.lock();
```
The suggestion would create a deadlock at the second `x.lock()` call.
This also lints even when a significant drop type isn't created as a temporary. (#9072)
I agree `@kpreid` (https://github.com/rust-lang/rust-clippy/issues/8987#issuecomment-1207464440) that this should be back-ported before the lint hits stable.
changelog: Move `significant_drop_in_scrutinee` into `nursey`
bors [Mon, 1 Aug 2022 12:16:45 +0000 (12:16 +0000)]
Auto merge of #9273 - tabokie:assert_ok_fp, r=flip1995
Move [`assertions_on_result_states`] to restriction
Close #9263
This lint causes regression on readability of code and log output. And printing runtime values is not particularly useful for majority of tests which should be reproducible.
changelog: Move [`assertions_on_result_states`] to restriction and don't lint it for unit type
Auto merge of #8974 - Metaswitch:remove-blacklist-terminology, r=Manishearth
Remove "blacklist" terminology
Picking up where https://github.com/rust-lang/rust-clippy/pull/5896 left off, this renames the `blacklisted_name` lint to `disallowed_names` (pluralised for compliance with naming conventions). The old name is still available though is deprecated (both in the lint name, and in the TOML configuration file).
This has been proposed/requested a few times, most recently in https://github.com/rust-lang/rust-clippy/issues/7582 where `@xFrednet` suggested pinging the Clippy team when a PR was created hence...
Auto merge of #9252 - Metaswitch:use-deprecated-config, r=Jarcho
Read and use deprecated configuration (as well as emitting a warning)
Original change written by `@flip1995` I've simply rebased to master and fixed up the formatting/tests. This change teaches the configuration parser which config key replaced a deprecated key and attempts to populate the latter from the former. If both keys are provided this fails with a duplicate key error (rather than attempting to guess which the user intended).
Currently this on affects `cyclomatic-complexity-threshold` -> `cognitive-complexity-threshold` but will also be used in #8974 to handle `blacklisted-names` -> `disallowed-names`.
```
changelog: deprecated configuration keys are still applied as if they were provided as their non-deprecated name.
```
- [x] `cargo test` passes locally
- [x] Run `cargo dev fmt`
David Wood [Mon, 25 Jul 2022 12:02:39 +0000 (13:02 +0100)]
lint: add bad opt access internal lint
Some command-line options accessible through `sess.opts` are best
accessed through wrapper functions on `Session`, `TyCtxt` or otherwise,
rather than through field access on the option struct in the `Session`.
Adds a new lint which triggers on those options that should be accessed
through a wrapper function so that this is prohibited. Options are
annotated with a new attribute `rustc_lint_opt_deny_field_access` which
can specify the error message (i.e. "use this other function instead")
to be emitted.
A simpler alternative would be to simply rename the options in the
option type so that it is clear they should not be used, however this
doesn't prevent uses, just discourages them. Another alternative would
be to make the option fields private, and adding accessor functions on
the option types, however the wrapper functions sometimes rely on
additional state from `Session` or `TyCtxt` which wouldn't be available
in an function on the option type, so the accessor would simply make the
field available and its use would be discouraged too.
Auto merge of #97313 - cjgillot:ast-lifetimes-anon, r=petrochenkov
Resolve function lifetime elision on the AST
~Based on https://github.com/rust-lang/rust/pull/97720~
Lifetime elision for functions is purely syntactic in nature, so can be resolved on the AST.
This PR replicates the elision logic and diagnostics on the AST, and replaces HIR-based resolution by a `delay_span_bug`.
This refactor allows for more consistent diagnostics, which don't have to guess the original code from HIR.
Auto merge of #9237 - Alexendoo:useless-format-spans, r=Jarcho
Fix `useless_format` spans for `format!("{foo}")`
Fixes #9234
changelog: [`useless_format`]: Fix spans for `format!("{foo}")`
https://github.com/rust-lang/rust/pull/94030 made our workaround unneeded, but by coincidence our test still passed [because `Span::new()` swaps `hi` & `lo` if needed](https://github.com/rust-lang/rust/blob/c32dcbba187d1ee0dbe92dc152cb9c2f3f42900c/compiler/rustc_span/src/span_encoding.rs#L86-L88). So with a single character variable like `format!("{x}")` it still worked