Replace "dyn-compatible" with "dyn compatible"

See rust-lang#126554 (comment)

compiler/rustc_const_eval/src/interpret/call.rs

@@ -614,7 +614,7 @@ impl<'tcx, M: Machine<'tcx>> InterpCx<'tcx, M> {
             // codegen'd / interpreted as virtual calls through the vtable.
             ty::InstanceKind::Virtual(def_id, idx) => {
                 let mut args = args.to_vec();
-                // We have to implement all "dyn-compatible receivers". So we have to go search for a
+                // We have to implement all "dyn compatible receivers". So we have to go search for a
                 // pointer or `dyn Trait` type, but it could be wrapped in newtypes. So recursively
                 // unwrap those newtypes until we are there.
                 // An `InPlace` does nothing here, we keep the original receiver intact. We can't

compiler/rustc_error_codes/src/error_codes/E0038.md

@@ -5,9 +5,9 @@ trait, written in type positions) but this was a bit too confusing, so we now
 write `dyn Trait`.
 
 Some traits are not allowed to be used as trait object types. The traits that
-are allowed to be used as trait object types are called "dyn-compatible"[^1]
+are allowed to be used as trait object types are called "dyn compatible"[^1]
 traits. Attempting to use a trait object type for a trait that is not
-dyn-compatible will trigger error E0038.
+dyn compatible will trigger error E0038.
 
 Two general aspects of trait object types give rise to the restrictions:
 
@@ -34,7 +34,7 @@ aspects.
 ### The trait requires `Self: Sized`
 
 Traits that are declared as `Trait: Sized` or which otherwise inherit a
-constraint of `Self:Sized` are not dyn-compatible.
+constraint of `Self:Sized` are not dyn compatible.
 
 The reasoning behind this is somewhat subtle. It derives from the fact that Rust
 requires (and defines) that every trait object type `dyn Trait` automatically
@@ -61,7 +61,7 @@ implement a sized trait like `Trait:Sized`. So, rather than allow an exception
 to the rule that `dyn Trait` always implements `Trait`, Rust chooses to prohibit
 such a `dyn Trait` from existing at all.
 
-Only unsized traits are considered dyn-compatible.
+Only unsized traits are considered dyn compatible.
 
 Generally, `Self: Sized` is used to indicate that the trait should not be used
 as a trait object. If the trait comes from your own crate, consider removing
@@ -106,7 +106,7 @@ fn call_foo(x: Box<dyn Trait>) {
 }
 ```
 
-If only some methods aren't dyn-compatible, you can add a `where Self: Sized`
+If only some methods aren't dyn compatible, you can add a `where Self: Sized`
 bound on them to mark them as explicitly unavailable to trait objects. The
 functionality will still be available to all other implementers, including
 `Box<dyn Trait>` which is itself sized (assuming you `impl Trait for Box<dyn
@@ -120,7 +120,7 @@ trait Trait {
 ```
 
 Now, `foo()` can no longer be called on a trait object, but you will now be
-allowed to make a trait object, and that will be able to call any dyn-compatible
+allowed to make a trait object, and that will be able to call any dyn compatible
 methods. With such a bound, one can still call `foo()` on types implementing
 that trait that aren't behind trait objects.
 
@@ -309,7 +309,7 @@ Here, the supertrait might have methods as follows:
 
 ```
 trait Super<A: ?Sized> {
-    fn get_a(&self) -> &A; // note that this is dyn-compatible!
+    fn get_a(&self) -> &A; // note that this is dyn compatible!
 }
 ```
 
@@ -318,8 +318,8 @@ If the trait `Trait` was deriving from something like `Super<String>` or
 `get_a()` will definitely return an object of that type.
 
 However, if it derives from `Super<Self>`, even though `Super` is
-dyn-compatible, the method `get_a()` would return an object of unknown type when
-called on the function. `Self` type parameters let us make dyn-compatible traits
+dyn compatible, the method `get_a()` would return an object of unknown type when
+called on the function. `Self` type parameters let us make dyn compatible traits
 no longer compatible, so they are forbidden when specifying supertraits.
 
 There's no easy fix for this. Generally, code will need to be refactored so that

compiler/rustc_error_codes/src/error_codes/E0802.md

@@ -1,4 +1,4 @@
-The `Async{Fn, FnMut, FnOnce}` traits are not yet `dyn`-compatible.
+The `Async{Fn, FnMut, FnOnce}` traits are not yet dyn compatible.
 
 Erroneous code example:
 

compiler/rustc_error_codes/src/lib.rs

@@ -625,7 +625,7 @@ E0802: 0802,
 //  E0314, // closure outlives stack frame
 //  E0315, // cannot invoke closure outside of its lifetime
 //  E0319, // trait impls for defaulted traits allowed just for structs/enums
-//  E0372, // coherence not dyn-compatible
+//  E0372, // coherence not dyn compatible
 //  E0385, // {} in an aliasable location
 //  E0402, // cannot use an outer type parameter in this context
 //  E0406, // merged into 420

compiler/rustc_feature/src/removed.rs

@@ -159,7 +159,7 @@ declare_features! (
     /// then removed. But there was no utility storing it separately, so now
     /// it's in this list.
     (removed, no_stack_check, "1.0.0", None, None),
-    /// Allows making `dyn Trait` well-formed even if `Trait` is not dyn-compatible (object safe).
+    /// Allows making `dyn Trait` well-formed even if `Trait` is not dyn compatible (object safe).
     /// Renamed to `dyn_compatible_for_dispatch`.
     (removed, object_safe_for_dispatch, "1.83.0", Some(43561),
      Some("renamed to `dyn_compatible_for_dispatch`")),

compiler/rustc_feature/src/unstable.rs

@@ -269,7 +269,7 @@ declare_features! (
     (unstable, doc_notable_trait, "1.52.0", Some(45040)),
     /// Allows using the `may_dangle` attribute (RFC 1327).
     (unstable, dropck_eyepatch, "1.10.0", Some(34761)),
-    /// Allows making `dyn Trait` well-formed even if `Trait` is not dyn-compatible[^1].
+    /// Allows making `dyn Trait` well-formed even if `Trait` is not dyn compatible[^1].
     /// In that case, `dyn Trait: Trait` does not hold. Moreover, coercions and
     /// casts in safe Rust to `dyn Trait` for such a `Trait` is also forbidden.
     ///

compiler/rustc_hir_analysis/src/coherence/mod.rs

@@ -184,7 +184,7 @@ fn check_object_overlap<'tcx>(
     // check for overlap with the automatic `impl Trait for dyn Trait`
     if let ty::Dynamic(data, ..) = trait_ref.self_ty().kind() {
         // This is something like `impl Trait1 for Trait2`. Illegal if
-        // Trait1 is a supertrait of Trait2 or Trait2 is not dyn-compatible.
+        // Trait1 is a supertrait of Trait2 or Trait2 is not dyn compatible.
 
         let component_def_ids = data.iter().flat_map(|predicate| {
             match predicate.skip_binder() {

compiler/rustc_hir_analysis/src/coherence/orphan.rs

@@ -116,7 +116,7 @@ pub(crate) fn orphan_check_impl(
         // We can allow f to be called on `dyn DynCompatibleTrait + AutoTrait`.
         //
         // If we didn't deny `impl AutoTrait for dyn Trait`, it would be unsound
-        // for the `DynCompatibleTrait` shown above to be dyn-compatible because someone
+        // for the `DynCompatibleTrait` shown above to be dyn compatible because someone
         // could take some type implementing `DynCompatibleTrait` but not `AutoTrait`,
         // unsize it to `dyn DynCompatibleTrait`, and call `.f()` which has no
         // concrete implementation (issue #50781).

compiler/rustc_hir_analysis/src/hir_ty_lowering/lint.rs

@@ -80,7 +80,7 @@ impl<'tcx> dyn HirTyLowerer<'tcx> + '_ {
             if self_ty.span.can_be_used_for_suggestions()
                 && !self.maybe_suggest_impl_trait(self_ty, &mut diag)
             {
-                // FIXME: Only emit this suggestion if the trait is dyn-compatible.
+                // FIXME: Only emit this suggestion if the trait is dyn compatible.
                 diag.multipart_suggestion_verbose(label, sugg, Applicability::MachineApplicable);
             }
             // Check if the impl trait that we are considering is an impl of a local trait.
@@ -102,7 +102,7 @@ impl<'tcx> dyn HirTyLowerer<'tcx> + '_ {
                 lint.primary_message("trait objects without an explicit `dyn` are deprecated");
                 if self_ty.span.can_be_used_for_suggestions() {
                     lint.multipart_suggestion_verbose(
-                        "if this is a dyn-compatible trait, use `dyn`",
+                        "if this is a dyn compatible trait, use `dyn`",
                         sugg,
                         Applicability::MachineApplicable,
                     );

compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs

@@ -771,7 +771,7 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> {
                 // give us a `QPath::TypeRelative` with a trait object as
                 // `qself`. In that case, we want to avoid registering a WF obligation
                 // for `dyn MyTrait`, since we don't actually need the trait
-                // to be dyn-compatible.
+                // to be dyn compatible.
                 // We manually call `register_wf_obligation` in the success path
                 // below.
                 let ty = self.lowerer().lower_ty(qself);

compiler/rustc_hir_typeck/src/method/confirm.rs

@@ -307,7 +307,7 @@ impl<'a, 'tcx> ConfirmContext<'a, 'tcx> {
                     // distinct types (e.g., if `Self` appeared as an
                     // argument type), but those cases have already
                     // been ruled out when we deemed the trait to be
-                    // "dyn-compatible".
+                    // "dyn compatible".
                     let original_poly_trait_ref = principal.with_self_ty(this.tcx, object_ty);
                     let upcast_poly_trait_ref = this.upcast(original_poly_trait_ref, trait_def_id);
                     let upcast_trait_ref =

compiler/rustc_lint/messages.ftl

@@ -507,7 +507,7 @@ lint_mixed_script_confusables =
     .includes_note = the usage includes {$includes}
     .note = please recheck to make sure their usages are indeed what you want
 
-lint_multiple_supertrait_upcastable = `{$ident}` is dyn-compatible and has multiple supertraits
+lint_multiple_supertrait_upcastable = `{$ident}` is dyn compatible and has multiple supertraits
 
 lint_named_argument_used_positionally = named argument `{$named_arg_name}` is not used by name
     .label_named_arg = this named argument is referred to by position in formatting string

compiler/rustc_lint/src/multiple_supertrait_upcastable.rs

@@ -4,7 +4,7 @@ use rustc_session::{declare_lint, declare_lint_pass};
 use crate::{LateContext, LateLintPass, LintContext};
 
 declare_lint! {
-    /// The `multiple_supertrait_upcastable` lint detects when a dyn-compatible trait has multiple
+    /// The `multiple_supertrait_upcastable` lint detects when a dyn compatible trait has multiple
     /// supertraits.
     ///
     /// ### Example
@@ -28,7 +28,7 @@ declare_lint! {
     /// additional overhead is justified.
     pub MULTIPLE_SUPERTRAIT_UPCASTABLE,
     Allow,
-    "detect when a dyn-compatible trait has multiple supertraits",
+    "detect when a dyn compatible trait has multiple supertraits",
     @feature_gate = multiple_supertrait_upcastable;
 }
 

compiler/rustc_middle/src/query/mod.rs

@@ -1367,7 +1367,7 @@ rustc_queries! {
         desc { |tcx| "determining dyn-compatibility of trait `{}`", tcx.def_path_str(trait_id) }
     }
     query is_dyn_compatible(trait_id: DefId) -> bool {
-        desc { |tcx| "checking if trait `{}` is dyn-compatible", tcx.def_path_str(trait_id) }
+        desc { |tcx| "checking if trait `{}` is dyn compatible", tcx.def_path_str(trait_id) }
     }
 
     /// Gets the ParameterEnvironment for a given item; this environment

compiler/rustc_middle/src/traits/mod.rs

@@ -796,7 +796,7 @@ impl DynCompatibilityViolation {
                 format!("it contains the generic associated type `{name}`").into()
             }
             DynCompatibilityViolation::AsyncFnTrait { .. } => {
-                "`async` function traits are not yet `dyn`-compatible".into()
+                "async function traits are not yet dyn compatible".into()
             }
         }
     }
@@ -904,7 +904,7 @@ impl DynCompatibilityViolationSolution {
     }
 }
 
-/// Reasons a method might not be dyn-compatible.
+/// Reasons a method might not be dyn compatible.
 #[derive(Clone, Debug, PartialEq, Eq, Hash, HashStable, PartialOrd, Ord)]
 pub enum MethodViolationCode {
     /// e.g., `fn foo()`

compiler/rustc_middle/src/ty/instance.rs

@@ -50,7 +50,7 @@ pub enum ReifyReason {
     /// * A vtable entry is directly converted to a function call (e.g. creating a fn ptr from a
     ///   method on a `dyn` object).
     /// * A function with `#[track_caller]` is converted to a function pointer
-    /// * If KCFI is enabled, creating a function pointer from a method on a dyn-compatible trait.
+    /// * If KCFI is enabled, creating a function pointer from a method on a dyn compatible trait.
     /// This includes the case of converting `::call`-like methods on closure-likes to function
     /// pointers.
     FnPtr,

compiler/rustc_middle/src/ty/print/pretty.rs

@@ -3115,7 +3115,7 @@ define_print! {
             ty::PredicateKind::Subtype(predicate) => p!(print(predicate)),
             ty::PredicateKind::Coerce(predicate) => p!(print(predicate)),
             ty::PredicateKind::DynCompatible(trait_def_id) => {
-                p!("the trait `", print_def_path(trait_def_id, &[]), "` is dyn-compatible")
+                p!("the trait `", print_def_path(trait_def_id, &[]), "` is dyn compatible")
             }
             ty::PredicateKind::ConstEquate(c1, c2) => {
                 p!("the constant `", print(c1), "` equals `", print(c2), "`")

compiler/rustc_monomorphize/src/collector.rs

@@ -120,7 +120,7 @@
 //! #### Unsizing Casts
 //! A subtle way of introducing use edges is by casting to a trait object.
 //! Since the resulting wide-pointer contains a reference to a vtable, we need to
-//! instantiate all dyn-compatible methods of the trait, as we need to store
+//! instantiate all dyn compatible methods of the trait, as we need to store
 //! pointers to these functions even if they never get called anywhere. This can
 //! be seen as a special case of taking a function reference.
 //!

compiler/rustc_next_trait_solver/src/solve/trait_goals.rs

@@ -792,7 +792,7 @@ where
         let cx = self.cx();
         let Goal { predicate: (a_ty, _), .. } = goal;
 
-        // Can only unsize to an dyn-compatible trait.
+        // Can only unsize to an dyn compatible trait.
         if b_data.principal_def_id().is_some_and(|def_id| !cx.trait_is_dyn_compatible(def_id)) {
             return Err(NoSolution);
         }

compiler/rustc_trait_selection/src/error_reporting/traits/mod.rs

@@ -430,7 +430,7 @@ pub fn report_dyn_incompatibility<'tcx>(
     let trait_str = tcx.def_path_str(trait_def_id);
 
     // Avoid errors diving into the details of the `AsyncFn` traits if this is
-    // a straightforward "`AsyncFn` is not yet `dyn`-compatible" error.
+    // a straightforward "`AsyncFn` is not yet dyn compatible" error.
     if tcx.trait_is_async_fn(trait_def_id) {
         let fn_trait: Symbol = violations
             .iter()
@@ -446,20 +446,20 @@ pub fn report_dyn_incompatibility<'tcx>(
             tcx.dcx(),
             span,
             E0802,
-            "the trait `{}` is not yet `dyn`-compatible",
+            "the trait `{}` is not yet dyn compatible",
             fn_trait
         );
         // Note: this check is quite imprecise.
         // Comparing the DefIds or similar would be better, but we can't store
         // DefIds in `DynCompatibilityViolation`.
         if fn_trait.as_str() == trait_str {
-            err.span_label(span, format!("`{fn_trait}` is not yet `dyn`-compatible"));
+            err.span_label(span, format!("`{fn_trait}` is not yet dyn compatible"));
         } else {
             let trait_str = tcx.def_path_str(trait_def_id);
             err.span_label(
                 span,
                 format!(
-                    "`{trait_str}` inherits from `{fn_trait}` which is not yet `dyn`-compatible'"
+                    "`{trait_str}` inherits from `{fn_trait}` which is not yet dyn compatible'"
                 ),
             );
         }
@@ -522,7 +522,7 @@ pub fn report_dyn_incompatibility<'tcx>(
     // FIXME(dyn_compat_renaming): Update the URL.
     err.span_note(
         note_span,
-        "for a trait to be \"dyn-compatible\" it needs to allow building a vtable to allow the call \
+        "for a trait to be dyn compatible it needs to allow building a vtable to allow the call \
          to be resolvable dynamically; for more information visit \
          <https://doc.rust-lang.org/reference/items/traits.html#object-safety>",
     );

compiler/rustc_trait_selection/src/traits/dyn_compatibility.rs

@@ -325,7 +325,7 @@ pub fn dyn_compatibility_violations_for_assoc_item(
     }
 
     match item.kind {
-        // Associated consts are never dyn-compatible, as they can't have `where` bounds yet at all,
+        // Associated consts are never dyn compatible, as they can't have `where` bounds yet at all,
         // and associated const bounds in trait objects aren't a thing yet either.
         ty::AssocKind::Const => {
             vec![DynCompatibilityViolation::AssocConst(item.name, item.ident(tcx).span)]
@@ -348,7 +348,7 @@ pub fn dyn_compatibility_violations_for_assoc_item(
                 DynCompatibilityViolation::Method(item.name, v, span)
             })
             .collect(),
-        // Associated types can only be dyn-compatible if they have `Self: Sized` bounds.
+        // Associated types can only be dyn compatible if they have `Self: Sized` bounds.
         ty::AssocKind::Type => {
             if !tcx.features().generic_associated_types_extended()
                 && !tcx.generics_of(item.def_id).is_own_empty()
@@ -526,7 +526,7 @@ fn virtual_call_violations_for_method<'tcx>(
 /// This code checks that `receiver_is_dispatchable` is correctly implemented.
 ///
 /// This check is outlined from the dyn-compatibility check to avoid cycles with
-/// layout computation, which relies on knowing whether methods are dyn-compatible.
+/// layout computation, which relies on knowing whether methods are dyn compatible.
 fn check_receiver_correct<'tcx>(tcx: TyCtxt<'tcx>, trait_def_id: DefId, method: ty::AssocItem) {
     if !is_vtable_safe_method(tcx, trait_def_id, method) {
         return;
@@ -663,7 +663,7 @@ fn object_ty_for_trait<'tcx>(
 /// a pointer.
 ///
 /// In practice, we cannot use `dyn Trait` explicitly in the obligation because it would result in
-/// a new check that `Trait` is dyn-compatible, creating a cycle (until dyn_compatible_for_dispatch
+/// a new check that `Trait` is dyn compatible, creating a cycle (until dyn_compatible_for_dispatch
 /// is stabilized, see tracking issue <https://github.com/rust-lang/rust/issues/43561>).
 /// Instead, we fudge a little by introducing a new type parameter `U` such that
 /// `Self: Unsize<U>` and `U: Trait + ?Sized`, and use `U` in place of `dyn Trait`.

compiler/rustc_type_ir/src/predicate_kind.rs

@@ -52,7 +52,7 @@ pub enum PredicateKind<I: Interner> {
     /// Prove a clause
     Clause(ClauseKind<I>),
 
-    /// Trait must be dyn-compatible.
+    /// Trait must be dyn compatible.
     DynCompatible(I::DefId),
 
     /// `T1 <: T2`

tests/ui/associated-consts/associated-const-in-trait.stderr

@@ -4,7 +4,7 @@ error[E0038]: the trait `Trait` cannot be made into an object
 LL | impl dyn Trait {
    |      ^^^^^^^^^ `Trait` cannot be made into an object
    |
-note: for a trait to be "dyn-compatible" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
+note: for a trait to be dyn compatible it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
   --> $DIR/associated-const-in-trait.rs:4:11
    |
 LL | trait Trait {
@@ -19,7 +19,7 @@ error[E0038]: the trait `Trait` cannot be made into an object
 LL |     const fn n() -> usize { Self::N }
    |                             ^^^^ `Trait` cannot be made into an object
    |
-note: for a trait to be "dyn-compatible" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
+note: for a trait to be dyn compatible it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
   --> $DIR/associated-const-in-trait.rs:4:11
    |
 LL | trait Trait {

tests/ui/associated-item/issue-48027.stderr

@@ -4,7 +4,7 @@ error[E0038]: the trait `Bar` cannot be made into an object
 LL | impl dyn Bar {}
    |      ^^^^^^^ `Bar` cannot be made into an object
    |
-note: for a trait to be "dyn-compatible" it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
+note: for a trait to be dyn compatible it needs to allow building a vtable to allow the call to be resolvable dynamically; for more information visit <https://doc.rust-lang.org/reference/items/traits.html#object-safety>
   --> $DIR/issue-48027.rs:2:11
    |
 LL | trait Bar {