Remove 'static requirement on try_as_dyn #150161

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

tracking issue: #144361

cc @theemathas can you find an unsoundness when combined with generic impls where there are no lifetimes, but reference other impls that have lifetimes with constraints? I couldn't find anything.

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

danielhenrymantilla · 2025-12-19T17:04:57Z

compiler/rustc_hir/src/hir.rs

+                    }
+                    LifetimeKind::ImplicitObjectLifetimeDefault
+                    | LifetimeKind::Error
+                    | LifetimeKind::Infer


Does this refer to '_ and/or "hidden behind &[mut]" lifetimes? I think those are analogous to unique, non-nameable-in-bounds, lifetimes, so this ought to be fine?

danielhenrymantilla · 2025-12-19T17:08:07Z

tests/ui/any/non_static.rs

+// Test that downcasting to a dyn trait works as expected
+const _: () = {
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&42_i32).is_none());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&()).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&[()]).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&()).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&42_u32).is_none());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&(&(), &())).is_none());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&(&(), &(), ())).is_none());
+
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&Struct(&42_u32)).is_none());
+};


Nit: it would be a bit more readable to have the const { assert! next to the impl in question, or to involve some macro to hide the outermost &; I feel like it's a tad harder to read which type is being tested exactly. But maybe it's just me 😅

danielhenrymantilla · 2025-12-19T17:08:11Z

tests/ui/any/non_static.rs

+// Only valid for 'static lifetimes -> returns None
+impl Trait for &'static u32 {}


Wait, does that mean that before this PR, (x: &'static u32).try_as_dyn::<dyn Trait>() would work, but with this, it won't anymore?

jup 💀 Maybe that's fixable by running it twice, once if the type is 'static and once without, but idk what the best thing here is for now

danielhenrymantilla · 2025-12-19T17:09:35Z

tests/ui/any/non_static.rs

+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&()).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&[()]).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&()).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&42_u32).is_none());


This one is a "regression", right? With the old design we could be involving a &'static u32 which is both : 'static, and implementing Trait in the classical sense. Perhaps we'll want a try_as_dyn_static() function as well, for those interested in this use case?

danielhenrymantilla · 2025-12-19T17:12:30Z

compiler/rustc_hir/src/hir.rs

+        if ty_lifetimes.visit_ty_unambig(self.self_ty).is_break() {
+            return false;


I think this function also needs to test for unicity of type params, lest impl<T> Trait for (T, T) {} be green-lit, which when intersected over the &u32 family of types, is just (&'t u32, &'t u32) impl in disguise.

If anything, do add that test case:

const _: () = { trait Homo {} impl<T> Homo for (T, T) {} // Let's pick `T = &'_ i32`. assert!(std::any::try_as_dyn::<_, dyn Homo>(&(&42_i32, &27_i32)).is_none()); };

danielhenrymantilla · 2025-12-19T17:17:41Z

tests/ui/any/non_static.rs

+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&42_i32).is_none());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&()).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&[()]).is_some());
+    assert!(std::any::try_as_dyn::<_, dyn Trait>(&&()).is_some());


I'd expect this line to fail atm since you Break on LifetimeKind::Infer 🤔

infer lifetimes are a different thing. unnamed lifetimes just get an empty name but a unique DefId.

danielhenrymantilla · 2025-12-19T17:22:47Z

compiler/rustc_hir/src/hir.rs

+        }
+        impl<'v> Visitor<'v> for LifetimeFinder {
+            type Result = ControlFlow<()>;
+            fn visit_lifetime(&mut self, lifetime: &'v Lifetime) -> Self::Result {


It would be nice in this function to stop tracking for<'any>-kind of lifetimes: those are part of the monomorphised info of the type, are they not? But this might require setting up a separate set of known-for<>-quantified lifetimes that ought to be ignored rather than seen-checked.

yea, I decided to just ignore those for now (sound but pessimistic again), but should def document that

danielhenrymantilla · 2025-12-19T17:27:05Z

compiler/rustc_next_trait_solver/src/solve/trait_goals.rs

+                if let TypingMode::Reflection = ecx.typing_mode()
+                    && !cx.is_fully_generic_for_reflection(impl_def_id)
+                {
+                    return Err(NoSolution);


This is way over my head, lol, but just to sanity-check: could this branch be hoisted to the beginning of the function, as in, any impl that is not fully_generic_for_reflection(), when checking in Reflection mode, ought to result in Err(NoSolution), right? As in, it's not specific to this double-Negative branch?

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

r? BoxyUwU

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

This comment has been minimized.

Sign in to view

oli-obk force-pushed the try_as_dyn_non_static branch from 01327be to e7ef1ee Compare December 19, 2025 15:38

Remove 'static requirement on try_as_dyn

29f1dba

oli-obk force-pushed the try_as_dyn_non_static branch from e7ef1ee to 29f1dba Compare December 19, 2025 16:44

danielhenrymantilla reviewed Dec 19, 2025

View reviewed changes

rustbot assigned BoxyUwU and unassigned SparrowLii Dec 19, 2025

		// Only valid for 'static lifetimes -> returns None
		impl Trait for &'static u32 {}

		if ty_lifetimes.visit_ty_unambig(self.self_ty).is_break() {
		return false;

Uh oh!

Remove 'static requirement on try_as_dyn #150161

Are you sure you want to change the base?

Remove 'static requirement on try_as_dyn #150161

Conversation

oli-obk commented Dec 19, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

rustbot commented Dec 19, 2025

Uh oh!

This comment has been minimized.

danielhenrymantilla left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielhenrymantilla Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielhenrymantilla Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielhenrymantilla Dec 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BoxyUwU commented Dec 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

oli-obk commented Dec 19, 2025 •

edited by rustbot

Loading

danielhenrymantilla left a comment •

edited by rustbot

Loading

danielhenrymantilla Dec 19, 2025 •

edited

Loading

danielhenrymantilla Dec 19, 2025 •

edited

Loading

danielhenrymantilla Dec 19, 2025 •

edited

Loading