Emit ForbiddenBound fatally if meeting complex bounds #149728

mu001999 · 2025-12-07T03:44:49Z

Bounds in binders are denied, hir items won't contain and index them. But nested items in the bounds will still be lowered to hir. And their parents, i.e., the block in bounds is not in hir. So that ICE happens when error handling requires visiting hir parents.

I think fixing this by aborting immediately when meeting complex bounds in binders is good enough.

Fixes #149695

rustbot · 2025-12-07T03:44:54Z

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

mu001999 · 2025-12-18T03:50:15Z

@rustbot reroll

jdonszelmann · 2026-01-05T15:54:29Z

compiler/rustc_ast_passes/src/feature_gate.rs

+                    // Issue #149695
+                    // Abort immediately otherwise items defined in complex bounds will be lowered into HIR,
+                    // which will cause ICEs when errors of the items visit unlowered parents.
+                    self.sess.dcx().emit_fatal(errors::ForbiddenBound { spans });


fatal errors are a little unfortunate since they prevent other errors from happening. Is there no way to actually filter them out of the nested items? Maybe by setting a flag on the visitor?

Sorry, I'm not sure what you mean. Did you mean skipping unlowered parents when visiting?

well, if I understand it correctly, there are bounds in nested items, that if they remain there into the HIR will mess up type checking when finding those. So your solution is to error fatally early, so we never get to type checking. But that means you also don't get to see any other errors in the compilation process. Can we not filter out these bounds so they just won't go into HIR anymore? Or am I misunderstanding the situation and is that not easily possible?

This ICE is because the error in the nested item needs visiting its parent which is complex bound contains nested items. Not due to bounds in nested items.

For the case in the issue:

#![feature(non_lifetime_binders)] fn produce() -> for<A: A< { #[derive(Hash)] enum A {} struct A<A>; } >> Trait{ } fn main() {}

Nested items in the complex bound for <A: A<{ ... }>> cause error and needs visiting its parent when reporting errors, and the parent points to the block in the trait ref. But we now won't lower the complex bound to hir, so that the block is not in hir also. And it's still the parent of the inner nested items, then ICE happens.

So did you mean that don't lower nested items to hir if they are in a complex bound?

IIUC, it may cause perf problem, because this needs checking whether an item is in a complex bound or not when lowering them, and lowering them is a separate procedure.

could you try how bad that perf problem is? I'll start you a perf run. Cause I don't like the fatal errors much :/

Ok, I will try to do that later

thanks! If it does end up being terrible, we can go this route

jdonszelmann · 2026-01-08T23:42:59Z

@rustbot author

rustbot · 2026-01-08T23:43:03Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

mu001999 · 2026-01-09T01:41:50Z

@rustbot review

jdonszelmann · 2026-01-09T09:38:23Z

@rusbot author

jdonszelmann · 2026-01-09T09:38:57Z

@rustbot blocked on #149728 (comment)

rustbot · 2026-01-09T12:02:36Z

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.

mu001999 · 2026-01-09T18:09:10Z

Hi @jdonszelmann, in the lastest rough change, I tried to filter nested items in the bound, and not lower them to hir.

dbg! shows it works:

[compiler/rustc_ast_lowering/src/lib.rs:527:17] "skipping lowering of {:?}" = "skipping lowering of {:?}"
[compiler/rustc_ast_lowering/src/lib.rs:527:17] def_id = DefId(0:6 ~ bad_bounds[bee6]::produce::{constant#0}::A)
[compiler/rustc_ast_lowering/src/lib.rs:527:17] "skipping lowering of {:?}" = "skipping lowering of {:?}"
[compiler/rustc_ast_lowering/src/lib.rs:527:17] def_id = DefId(0:7 ~ bad_bounds[bee6]::produce::{constant#0}::A::{constructor#0})
[compiler/rustc_ast_lowering/src/lib.rs:527:17] "skipping lowering of {:?}" = "skipping lowering of {:?}"
[compiler/rustc_ast_lowering/src/lib.rs:527:17] def_id = DefId(0:8 ~ bad_bounds[bee6]::produce::{constant#0}::A::A)
[compiler/rustc_ast_lowering/src/lib.rs:527:17] "skipping lowering of {:?}" = "skipping lowering of {:?}"
[compiler/rustc_ast_lowering/src/lib.rs:527:17] def_id = DefId(0:10 ~ bad_bounds[bee6]::produce::{constant#0}::A#1)
[compiler/rustc_ast_lowering/src/lib.rs:527:17] "skipping lowering of {:?}" = "skipping lowering of {:?}"
[compiler/rustc_ast_lowering/src/lib.rs:527:17] def_id = DefId(0:11 ~ bad_bounds[bee6]::produce::{constant#0}::{impl#0})

But there still be errors, because they still have LocalDefId, so that they can be result of many other queries. For example, after the change, a new ICE appears because type_of(bad_bounds[bee6]::produce::{constant#0}::{impl#0}).

Concrete content of the new ICE is:

error: internal compiler error: compiler/rustc_middle/src/hir/mod.rs:385:32: No HirId for DefId(0:11 ~ bad_bounds[bee6]::produce::{constant#0}::{impl#0})


thread 'rustc' (6902108) panicked at compiler/rustc_middle/src/hir/mod.rs:385:32:
Box<dyn Any>
stack backtrace:
   0: std::panicking::begin_panic::<rustc_errors::ExplicitBug>
             at /rustc/1b6e21e163baa0b20f119e17e3871910978a60b6/library/std/src/panicking.rs:761:5
   1: std::panic::panic_any::<rustc_errors::ExplicitBug>
             at /rustc/1b6e21e163baa0b20f119e17e3871910978a60b6/library/std/src/panic.rs:260:5
   2: <rustc_errors::diagnostic::BugAbort as rustc_errors::diagnostic::EmissionGuarantee>::emit_producing_guarantee
             at ./compiler/rustc_errors/src/diagnostic.rs:63:9
   3: <rustc_errors::diagnostic::Diag<rustc_errors::diagnostic::BugAbort>>::emit
             at ./compiler/rustc_errors/src/diagnostic.rs:1405:9
   4: <rustc_errors::DiagCtxtHandle>::bug::<alloc::string::String>
             at ./compiler/rustc_errors/src/lib.rs:1231:30
   5: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>::{closure#0}
             at ./compiler/rustc_middle/src/util/bug.rs:39:48
   6: rustc_middle::ty::context::tls::with_opt::<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}
             at ./compiler/rustc_middle/src/ty/context/tls.rs:136:23
   7: rustc_middle::ty::context::tls::with_context_opt::<rustc_middle::ty::context::tls::with_opt<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>::{closure#0}, !>
             at ./compiler/rustc_middle/src/ty/context/tls.rs:79:18
   8: rustc_middle::ty::context::tls::with_opt::<rustc_middle::util::bug::opt_span_bug_fmt<rustc_span::span_encoding::Span>::{closure#0}, !>
             at ./compiler/rustc_middle/src/ty/context/tls.rs:134:5
   9: rustc_middle::util::bug::opt_span_bug_fmt::<rustc_span::span_encoding::Span>
             at ./compiler/rustc_middle/src/util/bug.rs:33:5
  10: rustc_middle::util::bug::bug_fmt
             at ./compiler/rustc_middle/src/util/bug.rs:16:5
  11: rustc_middle::hir::provide::{closure#0}
             at ./compiler/rustc_middle/src/macros.rs:18:9
  12: <rustc_middle::hir::provide::{closure#0} as core::ops::function::FnOnce<(rustc_middle::ty::context::TyCtxt, rustc_span::def_id::LocalDefId)>>::call_once
             at /rustc/1b6e21e163baa0b20f119e17e3871910978a60b6/library/core/src/ops/function.rs:250:5
  13: rustc_query_impl::query_impl::local_def_id_to_hir_id::dynamic_query::{closure#2}::{closure#0}
             at ./compiler/rustc_query_impl/src/plumbing.rs:298:9
      [... omitted 22 frames ...]
  14: rustc_middle::query::inner::query_get_at::<rustc_data_structures::vec_cache::VecCache<rustc_span::def_id::LocalDefId, rustc_middle::query::erase::Erased<[u8; 8]>, rustc_query_system::dep_graph::graph::DepNodeIndex>>
             at ./compiler/rustc_middle/src/query/inner.rs:33:17
  15: <rustc_middle::query::plumbing::TyCtxtAt>::local_def_id_to_hir_id::<rustc_span::def_id::LocalDefId>
             at ./compiler/rustc_middle/src/query/plumbing.rs:415:31
  16: <rustc_middle::ty::context::TyCtxt>::local_def_id_to_hir_id::<rustc_span::def_id::LocalDefId>
             at ./compiler/rustc_middle/src/query/plumbing.rs:406:35
  17: rustc_hir_analysis::collect::type_of::type_of::{closure#0}
             at ./compiler/rustc_hir_analysis/src/collect/type_of.rs:56:22
  18: rustc_hir_analysis::collect::type_of::type_of
             at ./compiler/rustc_hir_analysis/src/collect/type_of.rs:21:1
  19: rustc_query_impl::query_impl::type_of::dynamic_query::{closure#2}::{closure#0}
             at ./compiler/rustc_query_impl/src/plumbing.rs:302:13
      [... omitted 22 frames ...]
  20: rustc_middle::query::inner::query_get_at::<rustc_query_system::query::caches::DefIdCache<rustc_middle::query::erase::Erased<[u8; 8]>>>
             at ./compiler/rustc_middle/src/query/inner.rs:33:17
  21: <rustc_middle::query::plumbing::TyCtxtAt>::type_of::<rustc_span::def_id::DefId>
             at ./compiler/rustc_middle/src/query/plumbing.rs:415:31
  22: <rustc_middle::ty::context::TyCtxt>::type_of::<rustc_span::def_id::DefId>
             at ./compiler/rustc_middle/src/query/plumbing.rs:406:35
  23: rustc_middle::ty::trait_def::trait_impls_of_provider
             at ./compiler/rustc_middle/src/ty/trait_def.rs:227:32
  24: rustc_query_impl::query_impl::trait_impls_of::dynamic_query::{closure#2}::{closure#0}
             at ./compiler/rustc_query_impl/src/plumbing.rs:298:9
      [... omitted 22 frames ...]
  25: rustc_middle::query::inner::query_get_at::<rustc_query_system::query::caches::DefIdCache<rustc_middle::query::erase::Erased<[u8; 8]>>>
             at ./compiler/rustc_middle/src/query/inner.rs:33:17
  26: <rustc_middle::query::plumbing::TyCtxtAt>::trait_impls_of::<rustc_span::def_id::DefId>
             at ./compiler/rustc_middle/src/query/plumbing.rs:415:31
  27: <rustc_middle::ty::context::TyCtxt>::trait_impls_of::<rustc_span::def_id::DefId>
             at ./compiler/rustc_middle/src/query/plumbing.rs:406:35
  28: <rustc_middle::ty::context::TyCtxt>::all_impls
             at ./compiler/rustc_middle/src/ty/trait_def.rs:194:68

mu001999 · 2026-01-09T18:11:01Z

I think at least it's more difficult than I expected. Do you have any suggestions?

mu001999 · 2026-01-17T00:02:06Z

in the lastest rough change, I tried to filter nested items in the bound, and not lower them to hir.

You can check the previous attempt 1253837

mu001999 · 2026-01-17T00:03:29Z

@rustbot label -S-blocked

rustbot assigned wesleywiser Dec 7, 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 7, 2025

This comment has been minimized.

Sign in to view

mu001999 force-pushed the fix/149695 branch from 888f87a to 84a0f1e Compare December 7, 2025 10:36

mu001999 changed the title ~~Emit ForbiddenBound fatally~~ Emit ForbiddenBound fatally if meeting complex bounds Dec 7, 2025

rustbot assigned jdonszelmann and unassigned wesleywiser Dec 18, 2025

jdonszelmann reviewed Jan 5, 2026

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Jan 8, 2026

rustbot 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 Jan 9, 2026

rustbot added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2026

mu001999 force-pushed the fix/149695 branch from 84a0f1e to 10657b6 Compare January 9, 2026 12:02

mu001999 marked this pull request as draft January 9, 2026 15:56

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 9, 2026

This comment has been minimized.

Sign in to view

Emit ForbiddenBound fatally if meeting complex bound

2b73c39

mu001999 force-pushed the fix/149695 branch from 1253837 to 2b73c39 Compare January 17, 2026 00:00

mu001999 marked this pull request as ready for review January 17, 2026 00:00

rustbot 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 Jan 17, 2026

rustbot removed the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Jan 17, 2026

Uh oh!

Emit ForbiddenBound fatally if meeting complex bounds #149728

Are you sure you want to change the base?

Emit ForbiddenBound fatally if meeting complex bounds #149728

Conversation

mu001999 commented Dec 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 7, 2025

Uh oh!

This comment has been minimized.

mu001999 commented Dec 18, 2025

Uh oh!

jdonszelmann Jan 5, 2026

Choose a reason for hiding this comment

Uh oh!

mu001999 Jan 5, 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!

jdonszelmann Jan 8, 2026

Choose a reason for hiding this comment

Uh oh!

mu001999 Jan 9, 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!

mu001999 Jan 9, 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!

mu001999 Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

mu001999 Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

jdonszelmann Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

jdonszelmann commented Jan 8, 2026

Uh oh!

rustbot commented Jan 8, 2026

Uh oh!

mu001999 commented Jan 9, 2026

Uh oh!

jdonszelmann commented Jan 9, 2026

Uh oh!

jdonszelmann commented Jan 9, 2026

Uh oh!

rustbot commented Jan 9, 2026

Uh oh!

This comment has been minimized.

mu001999 commented Jan 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mu001999 commented Jan 9, 2026

Uh oh!

This comment has been minimized.

mu001999 commented Jan 17, 2026

Uh oh!

mu001999 commented Jan 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

mu001999 commented Dec 7, 2025 •

edited

Loading

mu001999 Jan 5, 2026 •

edited

Loading

mu001999 Jan 9, 2026 •

edited

Loading

mu001999 Jan 9, 2026 •

edited

Loading

mu001999 commented Jan 9, 2026 •

edited

Loading