From 82ceed2add79244d53a960735a68ce85d55a4232 Mon Sep 17 00:00:00 2001 From: Oli Scherer Date: Wed, 21 Feb 2024 11:35:50 +0000 Subject: [PATCH] Specialization can switch to `DefineOpaqueTypes::Yes` without having an effect. The reason is that in specialization graph computation we use `DefiningAnchor::Error`, so there's no difference anyway. And in the other use cases, we * already errored in the specialization_graph computation, or * already errored in coherence, or * are comparing opaque types with inference variables already, or * there are no opaque types involved --- .../rustc_trait_selection/src/traits/specialize/mod.rs | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/compiler/rustc_trait_selection/src/traits/specialize/mod.rs b/compiler/rustc_trait_selection/src/traits/specialize/mod.rs index 43c750ebbb5..ab8d7d31e43 100644 --- a/compiler/rustc_trait_selection/src/traits/specialize/mod.rs +++ b/compiler/rustc_trait_selection/src/traits/specialize/mod.rs @@ -247,7 +247,12 @@ fn fulfill_implication<'tcx>( // do the impls unify? If not, no specialization. let Ok(InferOk { obligations: more_obligations, .. }) = infcx .at(&ObligationCause::dummy(), param_env) - .eq(DefineOpaqueTypes::No, source_trait, target_trait) + // Ok to use `Yes`, as all the generic params are already replaced by inference variables, + // which will match the opaque type no matter if it is defining or not. + // Any concrete type that would match the opaque would already be handled by coherence rules, + // and thus either be ok to match here and already have errored, or it won't match, in which + // case there is no issue anyway. + .eq(DefineOpaqueTypes::Yes, source_trait, target_trait) else { debug!("fulfill_implication: {:?} does not unify with {:?}", source_trait, target_trait); return Err(());