Move checking placeholder types in return types to `typeck` by Zoxc · Pull Request #153243 · rust-lang/rust

Zoxc · 2026-03-01T05:30:23Z

This moves checking placeholder types in return types from the fn_sig query to typeck. typeck computes the return value of the body which is used for error suggestions. This is done to prevent a query cycle between fn_sig and typeck.

Currently fn_sig is marked with cycle_delay_bug to deal with this cycle, but I'm not sure if it's sufficient as we need the query we resume to have a Value impl, which may not be fn_sig.

Functions such as fn foo() -> _ will now return as fn foo() -> <error> from fn_sig instead of using the return type of their bodies. This can hide some later errors, but that seems like a minor downside.

This is also a step towards removing query cycle recovery.

rustbot · 2026-03-01T05:30:27Z

HIR ty lowering was modified

cc @fmease

dingxiangfei2009 · 2026-03-01T17:46:40Z

Thank you for contribution! 🙇

@bors r+ rollup=always

rust-bors · 2026-03-01T17:46:42Z

📌 Commit 8ddc609 has been approved by dingxiangfei2009

It is now in the queue for this repository.

fmease · 2026-03-01T18:27:58Z

Currently fn_sig is marked with cycle_delay_bug to deal with this cycle, but I'm not sure if it's sufficient as we need the query we resume to have a Value impl, which may not be fn_sig.

I'm struggling to understand why you didn't remove cycle_delay_bug from query fn_sig then (plus the Value impl for PolyFnSig)? Is some other place still relying on fn_sig delaying cycle errors as bugs?

fmease · 2026-03-01T18:42:54Z

    tcx: TyCtxt<'tcx>,
    item_def_id: LocalDefId,
    tainted_by_errors: Cell<Option<ErrorGuaranteed>>,
+    suppress_placeholder_errors: Cell<bool>,


To be frank, I'm not super stoked about adding a hyper-specific field to ItemCtxt plus an "anonymous" Boolean parameter to various functions. This solution feels blunt(?) and slightly hacky.

I haven't had the time to think about alternative solutions yet if there are any. I believe it should be possible to localize this code a lot more even if that meant ~reverting parts of PR #125819 (before which this recovery was 'more local' IIRC).

(personally speaking I'm generally unhappy about this super invasive & complex recovery logic for an 'incredibly niche' user error; it's already caused me headaches in the past)

We could possibly split out placeholder errors into a separate HIR visitor, then just skip visiting return types as appropriate.

(personally speaking I'm generally unhappy about this super invasive & complex recovery logic for an 'incredibly niche' user error; it's already caused me headaches in the past)

I think we occasionally go too far in our quest for high quality error messages. If an obscure error message is causing problems for perf or code complexity I think removing it is totally reasonable.

Just to clarify: which user error is the incredibly niche one?

Just to clarify: which user error is the incredibly niche one?

So I don't know how often beginner or average users encounter this error or how helpful they find the suggestion, I'm talking about code like const C = 1; (no type annotation), static S: _ = 1; (_ in item signatures), fn f() -> _ { 0 } but also static A: [&str; _] = [];.

I get that they can be quite useful, so maybe I've exaggerated. Still, personally speaking I just never use _ like this to obtain the right type from the compiler, so I'm a bit biased.

It's just that I know the implementation is quite unwieldy and hairy. Most crucially calling typeck instead of type_of on items that usually mandate a type signature is prone to query cycles (e.g, I most recently had to fight them in RUST-143029) which can be quite hindering when developing new features.

We could possibly split out placeholder errors into a separate HIR visitor, then just skip visiting return types as appropriate.

ItemCtxt had a few more users then I expected, so this might not be a good idea as it could be easy to skip the separate visitor.

To be frank, I'm not super stoked about adding a hyper-specific field to ItemCtxt

agreed on this, even though it seems like the latter half seems to be "fixed". What does this PR look like without this?

_{in reply to #153243 (comment)}

Without this flag we emit generic error diagnostics per _ in return types plus one diagnostic that actually contains the specialized suggestion with multiple primary highlights.

Using diagnostic stashing + downgrading to delayed bugs I was able go get rid of this flag while preserving the desired behavior. I'll push that later to this PR.

fmease · 2026-03-01T18:47:51Z

Sorry, I'm gonna unapprove this for now due to #153243 (comment) (question) and #153243 (comment) (semi-actionable concern)

@bors r-

Zoxc · 2026-03-02T04:18:40Z

I'm struggling to understand why you didn't remove cycle_delay_bug from query fn_sig then (plus the Value impl for PolyFnSig)? Is some other place still relying on fn_sig delaying cycle errors as bugs?

It unhides unrelated cycle errors, so I kept it out here to keep the PR smaller.

Zoxc · 2026-03-27T02:29:58Z

@fmease Can this get a re-evaluation with the extra parameter now removed?

teor2345

Notes on changes in PR #155223.

View changes since this review

rustbot · 2026-09-10T13:57:31Z

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.

fmease · 2026-09-10T15:39:38Z

+        );
+    } else if let Some(sugg) = rustc_hir_analysis::suggest_impl_trait(
+        &tcx.infer_ctxt().build(ty::TypingMode::non_body_analysis()),
+        tcx.param_env(def_id),


Note to myself: We could avoid the query call by accepting the param_env from the caller. Furthermore, we might be able to reuse the InferCtxt from the caller's FnCtxt, although that one is "typeck_for_body", not "non_body_analysis" & maybe the InferCtxt is bricked after writeback?

View changes since the review

fmease · 2026-09-10T17:41:59Z

    tcx: TyCtxt<'tcx>,
    item_def_id: LocalDefId,
    tainted_by_errors: Cell<Option<ErrorGuaranteed>>,
+    suppress_placeholder_errors: Cell<bool>,


_{in reply to #153243 (comment)}

Without this flag we emit generic error diagnostics per _ in return types plus one diagnostic that actually contains the specialized suggestion with multiple primary highlights.

Using diagnostic stashing + downgrading to delayed bugs I was able go get rid of this flag while preserving the desired behavior. I'll push that later to this PR.

Instead of manually keeping track of whether to suppress "bad placeholder" diagnostics via flag `ItemCtxt.suppress_placeholder_errors` just stash the relevant diagnostics beforehand & steal them later on to delay them as bugs.

fmease · 2026-09-10T22:40:08Z

Since I've now contributed substantial changes to this PR in form of 3 commits, I'd like another reviewer to take a look at all the changes.

r? @nnethercote maybe? feel free to reassign

rust-bors · 2026-09-11T19:06:00Z

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

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 Mar 1, 2026

rustbot assigned dingxiangfei2009 Mar 1, 2026

This comment was marked as outdated.

Sign in to view

Zoxc mentioned this pull request Mar 1, 2026

Add per query cycle handlers and use them for representability #153028

Closed

dingxiangfei2009 reviewed Mar 1, 2026

View reviewed changes

Comment thread compiler/rustc_hir_analysis/src/collect.rs Outdated

dingxiangfei2009 reviewed Mar 1, 2026

View reviewed changes

Comment thread compiler/rustc_hir_analysis/src/collect.rs Outdated

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 1, 2026

fmease reviewed Mar 1, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 1, 2026

fmease self-assigned this Mar 1, 2026

This comment has been minimized.

Sign in to view

Zoxc force-pushed the fn-sig-placeholder-move branch from 8ddc609 to 3424ede Compare March 16, 2026 14:10

This comment has been minimized.

Sign in to view

fmease added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 28, 2026

This comment has been minimized.

Sign in to view

teor2345 reviewed Apr 20, 2026

View reviewed changes

Comment thread compiler/rustc_hir_analysis/src/collect.rs

fmease unassigned dingxiangfei2009 Sep 10, 2026

fmease force-pushed the fn-sig-placeholder-move branch from da8d686 to 9f17ce4 Compare September 10, 2026 13:57

Zoxc added 4 commits September 10, 2026 15:58

Move checking placeholder types in return types to typeck

72bc77d

Similar tests

8f44908

Changed tests

9d9f426

Remove suppress_ret_ty_placeholder_errors parameter

9f17ce4

This comment has been minimized.

Sign in to view

Bless parallel-rustc tests

76fb83e

fmease reviewed Sep 10, 2026

View reviewed changes

fmease force-pushed the fn-sig-placeholder-move branch 2 times, most recently from f883e4e to 4f8d202 Compare September 10, 2026 22:37

fmease added 2 commits September 11, 2026 00:38

Move ItemNoType check into report_placeholder_type_error

4f8d202

rustbot assigned nnethercote and unassigned fmease Sep 10, 2026

Uh oh!

Uh oh!

Conversation

Zoxc commented Mar 1, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 1, 2026

Uh oh!

This comment was marked as outdated.

Uh oh!

Uh oh!

dingxiangfei2009 commented Mar 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors Bot commented Mar 1, 2026

Uh oh!

fmease commented Mar 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease Mar 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Zoxc Mar 2, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Zoxc Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

jackh726 Sep 10, 2026

Choose a reason for hiding this comment

Uh oh!

fmease Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease commented Mar 1, 2026

Uh oh!

Zoxc commented Mar 2, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

Zoxc commented Mar 27, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

teor2345 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!

Uh oh!

rustbot commented Sep 10, 2026

Uh oh!

This comment has been minimized.

Uh oh!

fmease Sep 10, 2026 • 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!

fmease Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease commented Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-bors Bot commented Sep 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Zoxc commented Mar 1, 2026 •

edited by rustbot

Loading

dingxiangfei2009 commented Mar 1, 2026 •

edited

Loading

fmease commented Mar 1, 2026 •

edited

Loading

fmease Mar 1, 2026 •

edited

Loading

fmease Mar 3, 2026 •

edited

Loading

fmease Sep 10, 2026 •

edited

Loading

teor2345 left a comment •

edited by rustbot

Loading

fmease Sep 10, 2026 •

edited by rustbot

Loading

fmease Sep 10, 2026 •

edited

Loading

fmease commented Sep 10, 2026 •

edited

Loading