should_implement_trait triggers for next() where the return value has lifetimes #5004
Labels
C-bug
Category: Clippy is not doing the correct thing
Comments
eddyb
added a commit
to EmbarkStudios/spirt
that referenced
this issue
Dec 14, 2022
In no particular order, these are the suspicious and/or
not-entirely-addressed lints:
* `clippy::single_match_else`: permanently `#![allow(…)]`ed, as the
style it denies is important for readability
* `clippy::string_add`: permanently `#![allow(…)]`ed, as it's (IMO)
misguided (and perhaps buggy?)
* `(...: String) + "..."` is short for `{ let mut s = ...;
s.push_str("..."); s }`, *not something else*
* `clippy::match_same_arms`: `#[allow(…)]` moved to specific `match`es
where listing out the patterns individually is more important than what
the actual values are (i.e. grouping by the output values is
detrimental)
* `clippy::should_implement_trait`: `#![allow(…)]` moved to specific
module encountering this bug:
* rust-lang/rust-clippy#5004
* `clippy::unused_self`: `#[allow(…)]` moved to specific `impl` (where
`self` may be used in the future)
* `clippy::redundant_closure_call`: `#[allow(…)]` moved to specific
macro using a closure as a `try {...}` block
* `clippy::map_err_ignore`: had to be worked around because the
`map_err(|_|` it complains about have no information in the error, i.e.
those `Result`s *might as well be a newtyped `Option`*
* `clippy::nonminimal_bool`: had to be worked around by introducing
extra `if`s (which should make the logic clearer)
* long-term, `nonminimal_bool` could be a real hazard, if it suggests
e.g. rewriting `!(foo && foo_bar)` into `!foo || !foo_bar`, when the
point of the `&&` is to *group* a `foo_bar` check with its `foo`
*prerequisite*
<sub>(in fact, I need to comb through Rust-GPU looking for artifacts of
this lint, because I've seen in the past conditions that were rendered
unreadable by an outer `!` being *De Morgan*'d into a `&&`, where the
outer `!` may have just been coincidental from e.g. a `retain`/`filter`
predicate's keep/remove distinction, but with `||` the correlation
between the two sides was erased...)</sub>
Fixes #13
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This should not trigger the lint until we get generic associated types:
The text was updated successfully, but these errors were encountered: