RS-LIFE0001 · evidence

This page continues RS-LIFE0001 directly from its source docstring. Read its implementation.

Evidence

Each finding names the declaration, the lifetimes it states, and the line it states them on, and counts the input positions those lifetimes appear in. The repair is a choice, because deleting the annotation and keeping it for a reason the signature cannot show are both real answers. The value is the number of annotations elision would have produced identically.

Exceptions

A type, a trait, and an alias are not judged at all, because Rust states no elision rule for any of them and there is nothing to compare their annotation against.

A lifetime written in two input positions is never reported even where it reaches no output, because tying two inputs together is a constraint elision cannot state and the two signatures therefore do not mean the same thing. Where the body relies on the tie, deleting the annotation does not compile at all.

An output lifetime coming from one input with no receiver is left alone as well. It turns on how many lifetime positions the inputs hold in total, and a bare Node hides one where &str shows it, so the arity lives in the type definitions rather than in the signature. Clippy reads those definitions and reports that arrangement, and guessing at it here would mean reporting a signature that does not compile without its annotation.

Stable Rust also requires a lifetime used in an associated type binding under argument-position impl Trait to be named. That annotation is syntax the compiler demands rather than optional documentation, so the provider marks it and this rule leaves it alone.

References

• Cites “The Rust Reference”, lifetime elision. Open reference
• Cites “Rust API Guidelines”, C-STRUCT-BOUNDS and the cost of stating what is inferred. Open reference
• Cites “corrode”, do not worry about lifetimes. Open reference