While equality bounds/predicates $type = $type and $type == $type (#20041) are syntactically legal and stable (if cfg'ed out), they get rejected during AST validation (which is a pass rustdoc does run) and more importantly they're not on track to becoming part of the language / being implemented anytime soon — if ever.
- Therefore HIR equality predicates (
rustc_hir::hir::WherePredicateKind::EqPredicate) should in theory never reach rustdoc's cleaning procedures. Instead of lowering them to a cleaned counterpart, we should just panic!()/bug!() on them (or delay a bug if it turns out they're smh. reachable and return some dummy cleaned type).
- Contrary to the HIR, the middle::ty IR does send us equality predicates (
rustc_type_ir::predicate::ProjectionPredicate) but these don't correspond to the aforementioned "standalone" predicates but to associated item bindings / equality constraints (as in e.g., Iterator<Item = ()>). However, we resugar these back to their assoc item binding form, so they should never actually reach HTML/JSON rendering (assuming the resugaring step never fails).
- Unfortunately, as an intermediate step we do lower projection predicates to cleaned
EqPredicates which prevents us from removing that enum variant for now.
- For a long time now, I've wanted to rewrite predicate cleaning (to fix #113015 and #126432) which would remove that unnecessary extra step (among other niceties)
- My very WIP PR is fmease/rust#23. It stalled because it got quite nasty due to the existence of nested ATBs (assoc type bounds) (which even the compiler can't render properly, cc #127329)
- That's why this cleanup operation is (at least partially) blocked on that effort
- I want rustdoc to crash on any projection predicates it can't resugar
rustdoc::clean::types::WherePredicate::EqPredicaterustdoc_json_types::WherePredicate::EqPredicateWhile equality bounds/predicates
$type = $typeand$type == $type(#20041) are syntactically legal and stable (if cfg'ed out), they get rejected during AST validation (which is a pass rustdoc does run) and more importantly they're not on track to becoming part of the language / being implemented anytime soon — if ever.rustc_hir::hir::WherePredicateKind::EqPredicate) should in theory never reach rustdoc's cleaning procedures. Instead of lowering them to a cleaned counterpart, we should justpanic!()/bug!()on them (or delay a bug if it turns out they're smh. reachable and return some dummy cleaned type).rustc_type_ir::predicate::ProjectionPredicate) but these don't correspond to the aforementioned "standalone" predicates but to associated item bindings / equality constraints (as in e.g.,Iterator<Item = ()>). However, we resugar these back to their assoc item binding form, so they should never actually reach HTML/JSON rendering (assuming the resugaring step never fails).EqPredicateswhich prevents us from removing that enum variant for now.