Closures always implement FnOnce in new solver

[compiler-errors]

We should process [closure]: FnOnce(Tys...) -> Ty obligations before fallback and closure analysis. We can do this by taking advantage of the fact that FnOnce is always implemented by closures, even before we definitely know the closure kind.

Fixes compiler-errors/next-solver-hir-issues#15

r? @oli-obk (trying to spread the reviewer load for new trait solver prs, and this one is pretty self-contained, though feel free to reassign 😸)

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[lcnr]

Suggested change

	Some(closure_kind) => {
	// If the closure's kind doesn't extend the goal kind,
	// then the closure doesn't implement the trait.
	if !closure_kind.extends(goal_kind) {
	return Err(NoSolution);
	}
	}
	// Closure kind is not yet determined
	None => {
	// All closures implement `FnOnce`
	if goal_kind != ty::ClosureKind::FnOnce {
	// Otherwise, if we don't know the `ClosureKind`, ambiguity.
	return Ok(None);
	}
	}
	// If the closure's kind doesn't extend the goal kind,
	// then the closure doesn't implement the trait.
	Some(closure_kind) => {
	if !closure_kind.extends(goal_kind) {
	return Err(NoSolution);
	}
	}
	// Closure kind is not yet determined, so we return ambiguity unless
	// the expected kind is `FnOnce` as that is always implemented.
	None => {
	if goal_kind != ty::ClosureKind::FnOnce {
	return Ok(None);
	}
	}

style nit: having these kinds of nested comments imo makes the code more verbose and harder to read. Can't explain it well but I guess part of the issue is that I have to switch between reading the comment, and reading the actual source.

r=me with or without this nit applied

[lcnr]

r? @lcnr 😁

[compiler-errors]

@bors r=lcnr rollup (new solver)

[bors]

📌 Commit 177997e has been approved by lcnr

It is now in the queue for this repository.