Remove 'static requirement on try_as_dyn by oli-obk · Pull Request #150161 · rust-lang/rust

oli-obk · 2025-12-19T15:11:39Z

View all comments

tracking issue: #144361

cc @ivarflakstad @izagawd

rustbot · 2025-12-19T15:11:43Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

rustbot · 2025-12-19T15:11:45Z

r? @SparrowLii

rustbot has assigned @SparrowLii.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

danielhenrymantilla

Some drive-by comments; but I'm not rustc/HIR-savy, so take these with a grain of salt 🙇

View changes since this review

BoxyUwU · 2025-12-19T18:17:49Z

r? BoxyUwU

oli-obk · 2026-01-13T15:16:20Z

The hacky solution is obviously not a general fix. But I think it's progress. As a next step I will add the input type as a generic parameter on TryAsDynCompat, at which point we should be able to enforce (in borrowck) that the input type outlives any lifetimes on the dyn Trait or its generic parameters. So if a generic parameter T has a 'static bound, it could be used as an input type for a try_as_dyn irrespective of the bounds on the dyn Trait. In the other direction, we will likely end up rejecting many traits that have generic parameters as the bounds are not something that can be written in Rust.

theemathas · 2026-03-11T09:04:54Z

+
+### Each trait `where` bound with an associated type equality (`Type: Trait<Assoc = Type2>`) does not mention lifetime-infected parameters.
+
+Checking whether `Option<&'? str>: IntoIterator<Item = &'static str>` holds discriminates `'?` against `'static`.


This would already run into the "no 'static rule". I'm unsure if this rule is needed or not.

Very true, let's go with the following example, then:

impl<'a, 'b> Trait<'b> for &'a str where Option<&'a str>: IntoIterator<Item = &'b str>, {}

which amounts to having done:

impl<'a> Trait<'a> for &'a str {}

which brings us back to "no repetitions in header" (&'? str: Trait<'static> discriminates '? against 'static).

Suggested change

Checking whether `Option<&'? str>: IntoIterator<Item = &'static str>` holds discriminates `'?` against `'static`.

Associated-type equality bounds can very much amount to lifetime-infected parameter equality constraints, which are problematic as per the "at most one mention of each lifetime-infected parameter in header" rule.

To illustrate, with the following definitions, `&'? str: Trait<'static>` discriminates `'?` against `'static`:

```rust

impl<'a, 'b> Trait<'b> for &'a str

where

// &'a str = &'b str,

Option<&'a str>: IntoIterator<Item = &'b str>,

{}

impl<'a> Trait<'a> for &'a str {}

```

theemathas · 2026-03-11T09:06:03Z

+
+The most obvious one: if you have `impl IsStatic for &'static str`, then determining whether `&'? str : IsStatic` does hold amounts to discriminating `'? : 'static`.
+
+### Each outlives `where` bound (`Type: 'a` and `'a: 'b`) does not mention lifetime-infected parameters.


This page doesn't define "lifetime-infected parameter" anywhere.

theemathas · 2026-03-17T02:48:53Z

This PR's TypeId::trait_info_of method is unsound when combined with ptr_metadata and arbitrary_self_types_pointers. This unsoundness occurs because TypeId::trait_info_of does not check whether the trait is TryAsDynCompatible.

I'm unsure whether arbitrary_self_types_pointers is necessary for the unsoundness. See rust-lang/unsafe-code-guidelines#516.

The following code performs a use-after-free with this PR.

#![feature(type_info, ptr_metadata, arbitrary_self_types_pointers)]

use std::{
    any::TypeId,
    ptr::{self, DynMetadata},
};

type Payload = Box<i32>;

trait Trait {
    type Assoc;
    fn method(self: *const Self, value: Self::Assoc) -> &'static Payload;
}
struct Thing;
impl Trait for Thing {
    type Assoc = &'static Payload;
    fn method(self: *const Self, value: Self::Assoc) -> &'static Payload {
        value
    }
}

fn extend<'a>(payload: &'a Payload) -> &'static Payload {
    let metadata: DynMetadata<dyn Trait<Assoc = &'a Payload>> = const {
        TypeId::of::<Thing>()
            .trait_info_of::<dyn Trait<Assoc = &'a Payload>>()
            .unwrap()
            .get_vtable()
    };
    let ptr: *const dyn Trait<Assoc = &'a Payload> =
        ptr::from_raw_parts(std::ptr::null::<()>(), metadata);
    ptr.method(payload)
}

fn main() {
    let payload: Box<Payload> = Box::new(Box::new(1i32));
    let wrong: &'static Payload = extend(&*payload);
    drop(payload);
    println!("{wrong}");
}

Potential solutions include:

Add a (): TryAsDynCompatible<T> bound to TypeId::TraitInfoOf
- Alternatively, change the TryAsDynCompatible trait to be a bound like dyn Trait: TryAsDynCompatible<'a>, and have a separate SourceType: 'a bound. And add T: TryAsDynCompatible<'a> to TypeId::TraitInfoOf.
Change TraitImpl::get_vtable to be unsafe.

oli-obk · 2026-04-21T09:03:02Z

change the TryAsDynCompatible trait to be a bound like dyn Trait: TryAsDynCompatible<'a>, and have a separate SourceType: 'a bound.

hmm... and desugar dyn Trait: TryAsDynCompatible<'a> to adding a constraint on the lifetime 'foo of the trait object? Bidirectional outlives bounds? It feels a bit icky to connect it that way, but I guess so does (): TryAsDynCompatible

rustbot · 2026-04-21T09:28:02Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

oli-obk · 2026-04-21T11:27:27Z

@rustbot ready

…ure soundness

rustbot · 2026-04-23T11:09:30Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

BoxyUwU · 2026-05-01T12:21:36Z


+fn impl_is_fully_generic_for_reflection(tcx: TyCtxt<'_>, def_id: LocalDefId) -> bool {
+    tcx.impl_trait_header(def_id).is_fully_generic_for_reflection()
+        && tcx.explicit_predicates_of(def_id).is_fully_generic_for_reflection()


If we don't need to check elaborated clauses does that mean we actually don't need to check any predicates since we'll wind up proving them in Reflection mode too

View changes since the review

BoxyUwU · 2026-05-01T12:32:48Z

    }
+
+    /// Allow simple where bounds like `T: Debug`, but prevent any kind of
+    /// outlives bounds or uses of generic parameters on the right hand side.


this feels kind of arbitrary to me, Self parameters are not special in any way in the type system afaik, what's the reason we want this

View changes since the review

BoxyUwU · 2026-05-01T12:34:54Z

 }

+impl<'tcx> ImplTraitHeader<'tcx> {
+    /// For trait impls, checks whether the type and trait only have generic parameters in their


so sth like impl Trait for Vec<u32> would be considered not fully generic?

View changes since the review

no this is just "forbid repeated parameters and aliases" need to update this comment :3

BoxyUwU · 2026-05-01T12:35:01Z

+                }
+            }
+
+            fn visit_ty(&mut self, t: Ty<'tcx>) -> Self::Result {


no visit_const? I guess because equality of const generics is always applicable? comment :3

View changes since the review

BoxyUwU · 2026-05-01T12:35:12Z

+                }
+            }
+
+            fn visit_ty(&mut self, t: Ty<'tcx>) -> Self::Result {


no visit_const? I guess because equality of const generics is always applicable? comment :3

View changes since the review

BoxyUwU · 2026-05-01T12:42:09Z

    PostBorrowckAnalysis { defined_opaque_types: I::LocalDefIds },
+    /// During the evaluation of reflection logic that ignores lifetimes, we can only
+    /// handle impls that are fully generic over all lifetimes without constraints on
+    /// those lifetimes (other than implied bounds).


why other than implied bounds? unlike normal specialization we don't have a base impl whose lifetime constraints have been checked to hold which we can rely on.

impl<T> Trait for &'_ T seems problematic for try_as_dyn given noone can ever actually check T: '_

View changes since the review

i guess you can rely on wfness of the traitref the user wrote for the try_as_dyn 🤔 so yeah maybe that is fine?

BoxyUwU · 2026-05-01T12:47:10Z

-            return Err(());
+        match self.infcx.typing_mode() {
+            TypingMode::Coherence => {}
+            TypingMode::Reflection


why do we not handle reservation impls in reflection mode. is there a test for try_as_dyn'ing a trait ref which has a reservation impl

View changes since the review

BoxyUwU · 2026-05-01T12:49:45Z

@rustbot author

BoxyUwU · 2026-05-01T12:55:55Z

 }

-/// Returns `Some(&U)` if `T` can be coerced to the trait object type `U`. Otherwise, it returns `None`.
+/// Trait that is automatically implemented for all `dyn Trait<'b, C> + 'a` without assoc type bounds.


why no assoc type bounds? this trait just exists to ensure that the type being try_as_dyn'd outlives the lifetime bound of the resulting trait object right?

View changes since the review

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 19, 2025

rustbot assigned SparrowLii Dec 19, 2025

rustbot added the WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) label Dec 19, 2025