Fix typecks on some spurious fudged function input expectation #150316

ShoyuVanilla · 2025-12-23T18:59:26Z

What @lcnr said in https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/expectations.20from.20fudging.20are.20a.20mess.20.23149379/near/560625119 worked out for real 😄

r? lcnr

ShoyuVanilla · 2025-12-23T19:05:47Z

compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs

+        // This is skipped for the old solver: attempting trait solving there can
+        // trigger an overflow, which is a fatal error in the old solver but is
+        // treated as mere ambiguity by the next solver.
+        if self.next_trait_solver()


Unfortunately, checking function's bounds against the expected input tys regresses tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-2.rs in the old solver.

rust/tests/ui/higher-ranked/trait-bounds/hrtb-doesnt-borrow-self-2.rs

Lines 19 to 70 in 99ff3fb

impl<'a> Stream for &'a mut Repeat {

type Item = &'a u64;

fn next(self) -> Option<Self::Item> {

Some(&self.0)

}

}

pub struct Map<S, F> {

stream: S,

func: F,

}

impl<'a, A, F, T> Stream for &'a mut Map<A, F>

where

&'a mut A: Stream,

F: FnMut(<&'a mut A as Stream>::Item) -> T,

{

type Item = T;

fn next(self) -> Option<T> {

match self.stream.next() {

Some(item) => Some((self.func)(item)),

None => None,

}

}

}

pub struct Filter<S, F> {

stream: S,

func: F,

}

impl<'a, A, F, T> Stream for &'a mut Filter<A, F>

where

for<'b> &'b mut A: Stream<Item = T>, // <---- BAD

F: FnMut(&T) -> bool,

{

type Item = <&'a mut A as Stream>::Item;

fn next(self) -> Option<Self::Item> {

while let Some(item) = self.stream.next() {

if (self.func)(&item) {

return Some(item);

}

}

None

}

}

pub trait StreamExt

where

for<'b> &'b mut Self: Stream,

{

fn mapx<F>(self, func: F) -> Map<Self, F>

Evaluating the bounds for<'b> &'b mut Self: Stream on method StreamExt::mapx causes overflow while trying to consider the candidate &'_ mut Map<Map<Map<...>, _>, _>, _> and this ends up with a fatal error 😢

lcnr

I feel like this PR is currently doing multiple somewhat distinct changes in the same commit. Please split them up into separate commits (or PRs even)

View changes since this review

lcnr · 2025-12-23T20:04:03Z

compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs

+                            self.param_env,
+                            ty::ClauseKind::WellFormed(ty.into()),
+                        ));
+                    }


My intention was to check well-formedness of expected input tys and I thought this would do the thing as they are equated with formal input tys.
But it might be more correct to check them separately outside the fudge

ShoyuVanilla · 2025-12-24T06:22:36Z

I feel like this PR is currently doing multiple somewhat distinct changes in the same commit. Please split them up into separate commits (or PRs even)

Yeah, I tried to do two things, checking well-formedness of expected input tys and whether they meet the callee's where bounds 😅

I'll break them into three commits, one for adding tests from related issues, wf check, and where bound check, with blessed test output to visualize the influence of each changes.

rust-bors · 2026-01-15T01:00:51Z

☔ The latest upstream changes (presumably #151144) made this pull request unmergeable. Please resolve the merge conflicts.

…t tys that do not satisfy the callee bounds

rustbot · 2026-01-15T14:54:44Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

ShoyuVanilla · 2026-01-15T16:36:48Z

Sorry for the ping 😅 I've split the changes into multiple commits and blessed tests for each commit. Would this be okay?

lcnr · 2026-01-19T15:08:20Z

compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs

+                    ocx.try_evaluate_obligations().is_empty()
+                });
+                well_formed.then_some(expected_input_tys)
+            });


why and then instead of filter?

lcnr

the second change isn't necessary to avoid any breakage when switching solvers, is it?

I think to fix rust-lang/trait-system-refactor-initiative#259 we should just do f5acf22

I think these sorts of improvements are generally good, but don't like improvements which are only limited to the new solver. I would drop the second commit and then get back to that one once the new solver is stable

View changes since this review

ShoyuVanilla · 2026-01-19T16:44:41Z

Yeah, moving generalization outside of the fudge fixes the issue but it regresses back an improvement made by next-solver as said in #t-types/trait-system-refactor > diesel benchmark doesn't compile @ 💬

I'll try combining it with the third commit of this PR and if it doesn't fix the regression, I think this should be closed and revisited once the new solver is stabilized 😄

ShoyuVanilla · 2026-01-19T17:33:39Z

Yeah, moving generalization outside of the fudge fixes the issue but it regresses back an improvement made by next-solver as said in #t-types/trait-system-refactor > diesel benchmark doesn't compile @ 💬

I'll try combining it with the third commit of this PR and if it doesn't fix the regression, I think this should be closed and revisited once the new solver is stabilized 😄

Oops, the third commit + f5acf22 still regresses back tests/ui/traits/next-solver/lazy-nested-obligations-2.rs 😅 Closing this for now

rustbot assigned lcnr Dec 23, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 23, 2025

ShoyuVanilla commented Dec 23, 2025

View reviewed changes

lcnr reviewed Dec 23, 2025

View reviewed changes

ShoyuVanilla force-pushed the fudge-checks branch from bcc851d to 4b80bc2 Compare December 24, 2025 13:25

This comment has been minimized.

Sign in to view

ShoyuVanilla force-pushed the fudge-checks branch from 4b80bc2 to 443a2f3 Compare December 24, 2025 13:46

This comment has been minimized.

Sign in to view

ShoyuVanilla added 3 commits January 15, 2026 23:41

Add tests for issue number 89299 and 149881

bb68807

Do not use ill-formed input expectations when checking function calls

9f3e4d5

Weaken the expectation to ExpectRvalueLikeUnsized for expected inpu…

effd66a

…t tys that do not satisfy the callee bounds

ShoyuVanilla force-pushed the fudge-checks branch from 443a2f3 to effd66a Compare January 15, 2026 14:54

ShoyuVanilla requested a review from lcnr January 15, 2026 16:36

lcnr reviewed Jan 19, 2026

View reviewed changes

ShoyuVanilla closed this Jan 19, 2026

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 19, 2026

	impl<'a> Stream for &'a mut Repeat {
	type Item = &'a u64;
	fn next(self) -> Option<Self::Item> {
	Some(&self.0)
	}
	}

	pub struct Map<S, F> {
	stream: S,
	func: F,
	}

	impl<'a, A, F, T> Stream for &'a mut Map<A, F>
	where
	&'a mut A: Stream,
	F: FnMut(<&'a mut A as Stream>::Item) -> T,
	{
	type Item = T;
	fn next(self) -> Option<T> {
	match self.stream.next() {
	Some(item) => Some((self.func)(item)),
	None => None,
	}
	}
	}

	pub struct Filter<S, F> {
	stream: S,
	func: F,
	}

	impl<'a, A, F, T> Stream for &'a mut Filter<A, F>
	where
	for<'b> &'b mut A: Stream<Item = T>, // <---- BAD
	F: FnMut(&T) -> bool,
	{
	type Item = <&'a mut A as Stream>::Item;
	fn next(self) -> Option<Self::Item> {
	while let Some(item) = self.stream.next() {
	if (self.func)(&item) {
	return Some(item);
	}
	}
	None
	}
	}

	pub trait StreamExt
	where
	for<'b> &'b mut Self: Stream,
	{
	fn mapx<F>(self, func: F) -> Map<Self, F>

Uh oh!

Fix typecks on some spurious fudged function input expectation #150316

Fix typecks on some spurious fudged function input expectation #150316

Conversation

ShoyuVanilla commented Dec 23, 2025

Uh oh!

ShoyuVanilla Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

lcnr left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcnr Dec 23, 2025

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla Dec 24, 2025

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla commented Dec 24, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

rust-bors bot commented Jan 15, 2026

Uh oh!

rustbot commented Jan 15, 2026

Uh oh!

ShoyuVanilla commented Jan 15, 2026

Uh oh!

lcnr Jan 19, 2026

Choose a reason for hiding this comment

Uh oh!

lcnr left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShoyuVanilla commented Jan 19, 2026

Uh oh!

ShoyuVanilla commented Jan 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

lcnr left a comment •

edited by rustbot

Loading

lcnr left a comment •

edited by rustbot

Loading