Change:
pub(crate) cx: &'a mut core::DocContext<'tcx>, } <del> impl<'a, 'tcx> AutoTraitFinder<'a, 'tcx> { </del> <ins> impl<'a, 'tcx> AutoTraitFinder<'a, 'tcx> where 'tcx: 'a, // should be an implied bound; rustc bug #98852. { </ins> pub(crate) fn new(cx: &'a mut core::DocContext<'tcx>) -> Self { AutoTraitFinder { cx } }

Discussion:
Update: I originally thought it's a soundness issue, but it may not be, see comment This code compiles after ~although it shouldn't~: () label C-bug T-types regression-from-stable-to-nightly I-unsound A-NLL
WG-prioritization assigning priority (). label -I-prioritize +P-critical
I have yet to find a way to exploit this code for actual unsound behavior. Perhaps you know a way Preliminary experiments make it seem … possibly … more as if the call kinda ignores the explicit and infers a shorter lifetime instead.
E.g. this works but this doesn’t Same story with vs
I feel like the “predicate containing ” makes early-bound instead of late-bound which is probably what makes “a difference” here in terms of compiler behavior.
Early-bound vs late-bound makes sense for the change in behavior
I’m increasingly convinced that this is not really a soundness issue. The behavior is confusing though, so it is an issue. It’s almost as if the closure struct implementing the closure (which would be necessarily generic over the lifetimes it “captures” if implemented manually) did not get instantiated with the right lifetimes, but instead those were left inferred. I.e. would turn into something like if implemented by hand, but it currently behaves as if instead of something like is used, leaving the lifetime inferred/unspecified, and meaning that an error due to the constraint only appears if the calls (or other usages of the closure) put bounds on that inferred lifetime that are in conflict with the fact that is not true.
I agree that this is most likely not a soundness issue, but it's still confusing and fixing it in the future would be a breaking change. By looking closer at the source, the named lifetime that appears in the closure is indeed a free inference variable independent from the found in the defining scope. It behaves similarly to how theorized in the previous comment. Perhaps this counts an unintended stabilization. Re-requesting prioritization in light of this. label -I-unsound +I-prioritize
Prioritization assessment still holds (discussion on ). label -I-prioritize
I haven’t more thoroughly tested it, but adding bounds for all early-bound lifetime arguments of a function for a trait as in: seems to “fix” the problem (of incorrectly accepting this function).

If code after this transformation does indeed behave as desired, all that would be necessary is to identify what needs to be changed so it behaves as if such a dummy trait bound was present. Edit: Nevermind, this breaks down quickly, e.g. even for this example, being systematic about the thing as in will not compile, despite the fact that the original code does (and should) compile. Nonetheless, I still think it’s an interesting observation that adding such a trait bound (only to so it is not even used for calling ) somehow makes the code (“successfully”) fail again.