mirror of
https://github.com/rust-lang/rust.git
synced 2025-10-28 11:38:01 +00:00
7ea74358c8
Dont collect assoc ty item bounds from trait where clause for host effect predicates For background, we uplift `where Self::Assoc: Trait` bounds in a trait's where clauses into *item bounds* on `type Assoc;`. This is because before we *had* syntactical item bounds, users would express their item bounds like so. Let's opt out of doing this same behavior for `HostEffect` predicates like `where Self::Assoc: [const] Trait`. I left a comment in the code: ```rust // FIXME(const_trait_impl): We *could* uplift the // `where Self::Assoc: [const] Trait` bounds from the parent trait // here too, but we'd need to split `const_conditions` into two // queries (like we do for `trait_explicit_predicates_and_bounds`) // since we need to also filter the predicates *out* of the const // conditions or they lead to cycles in the trait solver when // utilizing these bounds. For now, let's do nothing. ``` As an aside, this was an ICE that was only triggerable when building libraries and not binaries because we never were calling `tcx.ensure_ok().explicit_implied_const_bounds(def_id);` on associated types like we should have been. I adjusted the calls to `ensure_ok` to make sure this happens, so we catch bugs like this in the future more easily. As another aside, I fixed the bound uplifting logic for *always const* predicates, since those act like normal clauses and have no notion of conditional constness. r? ```@oli-obk``` ```@fee1-dead``` or anyone really Fixes rust-lang/rust#133275
For high-level intro to how type checking works in rustc, see the type checking chapter of the rustc dev guide.