Change:
region_ctxt_fn, ) }); <del> debug!(?sig); </del> <ins> debug!(?unnormalized_sig); </ins> // IMPORTANT: We have to prove well formed for the function signature before // we normalize it, as otherwise types like `<&'a &'b () as Trait>::Assoc` // get normalized away, causing us to ignore the `'b: 'a` bound used by the function.

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --(Originally found ) I tried this code: I expected to see this happen: lifetime error, is not Instead, this happened: compiles <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Regression in nightly-2022-08-10 found 7 bors merge commits in the specified range commit[0] 2022-08-08: Auto merge of - compiler-errors:projection-msg, r=estebank commit[1] 2022-08-09: Auto merge of - cjgillot:noice-doc, r=camelid commit[2] 2022-08-09: Auto merge of - matthiaskrgr:rollup-gs56vlw, r=matthiaskrgr commit[3] 2022-08-09: Auto merge of - JakobDegen:no-invalidate-visitor, r=tmiasko commit[4] 2022-08-09: Auto merge of - Dylan-DPC:rollup-18tzp6q, r=Dylan-DPC commit[5] 2022-08-09: Auto merge of - lcnr:implied-bounds-pre-norm, r=lcnr commit[6] 2022-08-09: Auto merge of - notriddle:notriddle/implementors-js, r=GuillaumeGomez label T-types T-compiler regression-from-stable-to-stable I-unsound A-lifetimes
Hmm… maybe this is just a duplicate of ?
I went ahead and implemented the "hacky" fix in
Looks like an NLL regression. The following invalid example compiles in v1.63.0, where NLL is enabled by default:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Bug originally found by , which I've then reduced. I tried this code: I expected to see this happen: Instead, this happened: code compiles successfully and onwards modify labels: +I-unsound +regression-from-stable-to-stable -regression-untriaged This does not occur if the implied-lifetime-bounds array is in closure parameter position; so it looks like a bug w.r.t. not properly checking the closure output type implied bounds?does not help (as of )
Bisected to nightly-2022-08-10: <- looks maybe interesting
you beat me by one minute :) cc for being possible cause of this unsoundness?
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler -needs-triage
Oh, neat it did turn out to be a new soundness bug instead of a dupe of . Thanks for figuring out this was a regression,
for we have a terminator calling , i.e. a function which returns . This does not include the implied bounds. Checking that is WF requires proving which succeeds without checking the usable implied bounds of the trait-ref. edit: there's a bit more to this than I thought
This soundness bug is effectively only reproducible via the traits because the impls for it are builtin and so a little screwy. An attempt to write an explicit impl for the builtin impls would require an explicit bound that holds which is not present on the builtin impl. There is an assumption that all it takes for an assoc type to be wf is the where clauses on it and the impl hold, and that all arguments in the traitref are wf. The builtin impls violate this by not having the required implied bound on the impl so we end up with being able to be proven wf without proving the implied bounds. When calling we check that the fn sig of is wf which is . Before we would check the normalized signature is wf so the return type would be which would cause us to prove . Now that we check the unnormalized_ signature is wf we end up never seeing the normalized form with the which introduces the implied bound. It is generally an invariant of the type system that holding should imply also holds. The fact that can be well formed but is not, is concerning.

In an ideal world proving the traits would require also proving all the implied bounds hold but right now that is not possible afaik. A simple fix (albeit hacky until we make implied bounds desugared to actual bounds) would be to make us also check not just .