bjoernager/rust
bjoernager/rust
1
Fork 0
Code Activity

Rollup merge of #136968 - oli-obk:bye-bye, r=compiler-errors

Browse source 
Turn order dependent trait objects future incompat warning into a hard error

fixes #56484

r? ``@ghost``

will FCP when we have a crater result
This commit is contained in:
Matthias Krüger 2025-03-09 10:34:47 +01:00 • committed by GitHub
commit 5a46f82d7e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
13 changed files with 38 additions and 330 deletions
Download patch file Download diff file Expand all files Collapse all files

47
compiler/rustc_middle/src/ty/mod.rs
View file

@ -1414,39 +1414,6 @@ pub enum ImplOverlapKind {
/// Whether or not the impl is permitted due to the trait being a `#[marker]` trait
marker: bool,
},
/// These impls are allowed to overlap, but that raises an
/// issue #33140 future-compatibility warning (tracked in #56484).
///
/// Some background: in Rust 1.0, the trait-object types `Send + Sync` (today's
/// `dyn Send + Sync`) and `Sync + Send` (now `dyn Sync + Send`) were different.
///
/// The widely-used version 0.1.0 of the crate `traitobject` had accidentally relied on
/// that difference, doing what reduces to the following set of impls:
///
/// ```compile_fail,(E0119)
/// trait Trait {}
/// impl Trait for dyn Send + Sync {}
/// impl Trait for dyn Sync + Send {}
/// ```
///
/// Obviously, once we made these types be identical, that code causes a coherence
/// error and a fairly big headache for us. However, luckily for us, the trait
/// `Trait` used in this case is basically a marker trait, and therefore having
/// overlapping impls for it is sound.
///
/// To handle this, we basically regard the trait as a marker trait, with an additional
/// future-compatibility warning. To avoid accidentally "stabilizing" this feature,
/// it has the following restrictions:
///
/// 1. The trait must indeed be a marker-like trait (i.e., no items), and must be
/// positive impls.
/// 2. The trait-ref of both impls must be equal.
/// 3. The trait-ref of both impls must be a trait object type consisting only of
/// marker traits.
/// 4. Neither of the impls can have any where-clauses.
///
/// Once `traitobject` 0.1.0 is no longer an active concern, this hack can be removed.
FutureCompatOrderDepTraitObjects,
}
/// Useful source information about where a desugared associated type for an
@ -1624,7 +1591,7 @@ impl<'tcx> TyCtxt<'tcx> {
})
}
/// Returns `true` if the impls are the same polarity and the trait either
/// Returns `Some` if the impls are the same polarity and the trait either
/// has no items or is annotated `#[marker]` and prevents item overrides.
#[instrument(level = "debug", skip(self), ret)]
pub fn impls_are_allowed_to_overlap(
@ -1665,18 +1632,6 @@ impl<'tcx> TyCtxt<'tcx> {
return Some(ImplOverlapKind::Permitted { marker: true });
}
if let Some(self_ty1) =
self.self_ty_of_trait_impl_enabling_order_dep_trait_object_hack(def_id1)
&& let Some(self_ty2) =
self.self_ty_of_trait_impl_enabling_order_dep_trait_object_hack(def_id2)
{
if self_ty1 == self_ty2 {
return Some(ImplOverlapKind::FutureCompatOrderDepTraitObjects);
} else {
debug!("found {self_ty1:?} != {self_ty2:?}");
}
}
None
}