Passing a lifetime GAT to a closure can cause the compiler to run indefinitely #108826
Description
Code
I tried to pair it down more, but so far this is the smallest version I could get to cause the issue:
pub trait LendingIterator {
type Item<'a>
where
Self: 'a;
fn next<'a>(&'a mut self) -> Self::Item<'a>
where
Self: 'a;
fn filter<P>(self, predicate: P) -> Filter<Self, P>
where
Self: Sized,
for<'a> P: FnMut(&Self::Item<'a>) -> bool,
{
Filter {
stream: self,
predicate,
}
}
}
#[derive(Clone, Debug)]
pub struct Filter<S, P> {
stream: S,
predicate: P,
}
impl<S, P> LendingIterator for Filter<S, P>
where
S: LendingIterator + Unpin,
for<'a> P: FnMut(&Self::Item<'a>) -> bool,
{
type Item<'a> = S::Item<'a> where S: 'a;
fn next<'a>(&'a mut self) -> Self::Item<'a>
where
Self: 'a,
{
loop {
let next = self.stream.next()?;
if (self.predicate)(&next) {
return Some(());
}
}
}
}Meta
rustc --version --verbose:
rustc 1.70.0-nightly (7820b62d2 2023-03-05)
binary: rustc
commit-hash: 7820b62d20bc548096d4632a3487987308cb4b5d
commit-date: 2023-03-05
host: x86_64-pc-windows-msvc
release: 1.70.0-nightly
LLVM version: 15.0.7
and
rustc 1.67.1 (d5a82bbd2 2023-02-07)
binary: rustc
commit-hash: d5a82bbd26e1ad8b7401f6a718a9c57c96905483
commit-date: 2023-02-07
host: x86_64-pc-windows-gnu
release: 1.67.1
LLVM version: 15.0.6
Error output
There isn't any error output, since the compiler runs indefinitely when encountering this issue.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
jihiggins commentedon Mar 6, 2023
It looks like it's not the reference part, I found a case that also causes it where the predicate doesn't take the value by reference, and another case where taking it by reference doesn't cause this behavior
[-]Lifetime GATs passed by reference to a closure cause the compiler to run forever[/-][+]Passing a lifetime GAT to a closure can cause the compiler to run indefinitely[/+]fmease commentedon Mar 6, 2023
Teapot4195 commentedon Mar 8, 2023
Backtrace
repeating stack is frame 62 to 85 + select() call @ 2543
2544+ is probably unnesesary but I included it anyways.
fmease commentedon Mar 10, 2023
Alright, I've investigated this a bit. This regressed in #81055 which set out to make some overflow errors recoverable (undoing parts of #80246). If I locally revert the change made in #81055, the modified compiler correctly bails out early and reports the following overflow error:
Issue #81091 seems very relevant here (if a PR implements the proposal in #81091, I assume this issue will be fixed by it, too).
fmease commentedon Mar 11, 2023
Further minimized:
jihiggins commentedon Mar 11, 2023
Sorry if this is the wrong place to ask, but is there a way to accomplish a similar thing without running into the trait evaluation recursion?
fmease commentedon Mar 13, 2023
To make it compile,
LendingIterator::nextneeds to return anOption.Here is a link to a working version.
fmease commentedon Mar 13, 2023
And to work around the borrow checker limitation mentioned on that playground, you may want to consider using polonius-the-crab.
jihiggins commentedon Mar 13, 2023
Awesome, thanks!
fmease commentedon Aug 21, 2023
Fixed by next solver (
-Zsolver=next):@rustbot label fixed-by-next-solver
Nadrieril commentedon Jun 15, 2024
Found a similar issue that doesn't use GATs directly, in case that's useful: