Repository navigation
Feature DFV makes addition of trait impls breaking (apart from 1IR) since we don't reject trivially unsatisfiable clauses on ADTs with DFVs #165152
Description
A sequel to #146496. "Trivially unsatisfiable clauses" aka "trivial bounds" aka "impossible bounds" aka "false global bounds" were briefly alluded to by [@]lcnr in #t-types/nominated > #146496: The way `default_field_values` deals with in-scope… @ 💬 and they were also a topic brought up separately by [@]BoxyUwU in the context of GCI (feature generic_const_items), see #142293 (comment).
Reproducer
Upstream crate upstream:
pub trait Trait { const THING: (); }
// NOTE: Adding this innocuous-looking impl breaks downstream.
//impl Trait for () { const THING: () = (); }Downstream crate downstream:
#![feature(default_field_values)]
struct Type
where
for<'_delay> (): upstream::Trait,
{
field: () = {
let _ = <() as upstream::Trait>::THING;
panic!() // NOTE: Panics if upstream adds the impl.
},
}Here, we const_eval_poly the default of Type.field which bails out early without error (probably with ErrorHandled::TooGeneric) once it encounters the const projection since the type doesn't really implement the trait, it's only an assumption in the environment.
We try to avoid introducing features that make adding trait impls1 (more) breaking. "More" breaking because 1IR (the "one-impl rule") is the main offender already. A semi-offender would be const blocks in a function with trivially unsatisfiable bounds ("semi" because it can "only" lead to post-mono breakages).
Footnotes
-
We're ignoring pathological impls here that contain associated consts or const fns that unconditionally diverge, etc. It gets blurry really fast because the RHS of non-type-system const exprs is not really considered part of the public API... ↩
Activity
[-]DFV: Addition of trait impl is breaking (apart from 1IR) since we don't reject trivially unsatisfiable (modulo regions) clauses on ADTs with DFVs[/-][+]DFV: Addition of trait impl is breaking (apart from 1IR) since we don't reject trivially unsatisfiable clauses on ADTs with DFVs[/+]fmease commentedon Oct 29, 2026
In the title I once stated "trivially unsatisfiable (modulo regions)" because bounds that reference early-bound regions (e.g.,
<'a> &'a (): upstream::Traitare also iffy and "confuse" const eval but I couldn't come up with a similar reproducer...fmease commentedon Oct 29, 2026
One solution Boxy once suggested for GCI was to flat out reject trivial bounds in cases like this (CC #142293 (comment)) (edit: Now tracked in #165153).
[-]DFV: Addition of trait impl is breaking (apart from 1IR) since we don't reject trivially unsatisfiable clauses on ADTs with DFVs[/-][+]Feature DFV makes addition of trait impls breaking (apart from 1IR) since we don't reject trivially unsatisfiable clauses on ADTs with DFVs[/+]