sqlparser regression: normalizes-to impl-where clauses are nonproductive

[compiler-errors]

https://crater-reports.s3.amazonaws.com/pr-133502-1/try%23fa8e241660363f48d64b66b05eea58c93ab828fb/reg/sqlparser-0.55.0/log.txt

Minimized:

fn test<T>()
where
    <Vec<T> as IntoIterator>::IntoIter: Iterator,
{
}

[compiler-errors]

Something iffy going on with alias-relate 💀

[compiler-errors]

As far as I can tell, this is the root cause:

Normalizing <Vec<T> as IntoIterator>::IntoIter assembles two candidates:

1. The one we expect, via the impl IntoIterator for Vec<T> in libstd.
2. The one via the blanket impl IntoIterator for T where T: Iterator. This requires proving Vec<T>: Iterator, which requires alias-relating Vec<T> and <Vec<T> as IntoIterator>::IntoIter. Doing that requires normalizing <Vec<T> as IntoIterator>::IntoIter, which is a cycle, leading to ambiguity.

[compiler-errors]

There may be an additional layer of shenanigans going on with NestedNormalizationGoals.

[lcnr]

changing the root goal so that it's easier to think about:

• Vec<T>: Iterator
  • via env <Vec<T> as IntoIterator>::IntoIter: Iterator
    • Vec<T> eq <Vec<T> as IntoIterator>::IntoIter
      • normalize <Vec<T> as IntoIterator>::IntoIter
        • via impl<I: Iterator> IntoIterator for I
          • prove where-bound Vec<T>: Iterator cycle
        • via impl<T> IntoIterator for Vec<T> ~> trivial

Clearly Vec<T>: Iterator should not hold in an empty environment and proving <Vec<T> as IntoIterator>::IntoIter: Iterator should succeed. If we were to treat this cycle as productive, and dealt with the resulting ambiguity in some way, Vec<T>: Iterator could hold. So this cycle has to be unproductive and should result in an error.

I would need to actually lower this the dictionary passing style to fully understand what's going on, but my understanding is that even though we enter the impl<I: Iterator> IntoIterator for I by normalizing to its associated item, we exit the "impl constructor" again, so this cycle is not productive.

How to actually implement this in rustc is interesting and needs some further thought :> I am done for today