Forbid freely casting lifetime bounds of dyn-types #136776

BoxyUwU · 2025-02-09T16:27:39Z

Reference PR:

Reference updates for forbidding object lifetime changing pointer casts reference#1951

Background reading about VTable calls/dyn compatibility: https://hackmd.io/zUp-sgZ0RFuFgsNfD4JqYw

This PR causes us to start enforcing that lifetimes of dyn types are constrained through pointer casts. Currently on stable casting *mut dyn Trait + 'a to *mut dyn Trait + 'b passes with no requirements on 'a or 'b. Under this PR we now require 'a to outlive 'b.

Even though the pointee of *mut pointers is considered to be invariant, we still use subtyping rather than equality. This mirrors how we support coercing &mut dyn Trait + 'a to &mut dyn Trait + 'b while requiring only 'a: 'b. I believe this coercion is sound as there is no way for safe code to mem::swap two dyn Trait's, and the same is definitely true of raw pointers.

See the changes to this test: https://github.com/rust-lang/rust/pull/136776/files#diff-5523f20a800287a89c9f3e92646c887f3f7599be006b29dd9315f734a2137764

We also do not enforce any constraints on the lifetime of the dyn types if there are multiple pointer indirections. For example *mut *mut dyn Trait + 'a is allowed to be casted to *mut *mut dyn Trait + 'b with no requirements on 'a or 'b`. This case is just a normal thin pointer cast where we do not care about the pointee type as there is no VTable in play.

Test: https://github.com/rust-lang/rust/pull/136776/files#diff-3b6c8da342bb6530524158d686455a545bb8fd6f59cf5ff50d1d991ce74c9649

Finally, this is about any cast where the pointee is unsized with dyn-type metadata, not just literally the pointee type being a dyn-type. E.g. casting *mut Wrapper<dyn Trait + 'a> to *mut Wrapper<dyn Trait + 'b> requires 'a: 'b under this PR.

Test: https://github.com/rust-lang/rust/pull/136776/files#diff-ca0c44df62ae1ad1be70f892f01a59714336c7baf78602a5887ac1cf81145c96

Breakage

This is a breaking change.
Crater Report Comment: #136776 (comment)
Generated Report: https://crater-reports.s3.amazonaws.com/pr-136776/index.html

The majority of the breakage is caused by the metrics crate with 142 of the regressions, and the may crate with 14 of the regressions. The metrics crate has been fixed and has backported the fix to previous versions of the crate that were also affected. Themay crate has also been fixed.

PRs against affected crates have been opened and can be seen here:

There were three regressions I've not filed PRs against:

https://github.com/weiznich/diesel_benches depends on a ~6year old version of diesel (where the regression is)
https://crates.io/crates/cogo/0.1.36 is an old version of cogo, since that release cogo has already been updated to not depend on pattern this PR breaks
https://github.com/cruise-automation/webviz-rust-framework is an archived read only repo so 🤷‍♀️

r? @ghost

BoxyUwU · 2025-02-09T16:28:44Z

@bors try

…, r=<try> [WIP] Forbid object lifetime changing pointer casts Fixes rust-lang#136702 r? `@ghost`

bors · 2025-02-09T16:29:55Z

⌛ Trying commit d5ebeac with merge 44f3504...

bors · 2025-02-09T18:19:08Z

☀️ Try build successful - checks-actions
Build commit: 44f3504 (44f3504e96c944ae54fc72b5f5008f53f7eda001)

BoxyUwU · 2025-02-09T23:05:13Z

@craterbot check

craterbot · 2025-02-09T23:05:31Z

👌 Experiment pr-136776 created and queued.
🤖 Automatically detected try build 44f3504
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-02-10T07:05:49Z

🚧 Experiment pr-136776 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-02-11T04:22:14Z

🎉 Experiment pr-136776 is completed!
📊 169 regressed and 4 fixed (580506 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

RalfJung · 2025-02-11T07:41:02Z

Most of these are on github; in terms of crates.io regressions all we have is:

may
a bunch of crates using metrics, see e.g. this (for metrics-0.23) or this (for metrics-0.24, the latest version)

Overall, 142 regressions are caused by metrics and 14 by may; if we ca get fixed versions of those crates out that seems to mostly cover it.

EDIT: Ah, there's also cogo.

traviscross · 2025-02-12T17:11:11Z

We discussed this in the lang triage call today. We wanted to think more about it, so we're leaving it nominated to discuss again.

tmandry · 2025-02-19T16:44:01Z

@BoxyUwU Do you think it would be possible to implement this as an FCW? We talked about this in lang triage today and would prefer to start with that if we can. If it's not feasible, a hard error can also work (I would say though that we should upstream PRs to any crates we break).

Another small thing I noticed is that the error message links to the Nomicon section on variance, but it would be ideal to link to a tracking issue or something describing this issue in particular.

traviscross · 2025-02-19T17:10:04Z

To add on to what tmandry, said, in our discussions we did feel that the approach taken in this PR is generally the right way forward, and we're happy to see this progress so as to help clear the way for arbitrary_self_types and derive_coerce_pointee.

cc @rust-lang/lang

BoxyUwU · 2025-02-26T20:04:22Z

@tmandry I do expect it to be possible to FCW this. We can likely do something hacky around to fully emulate the fix (but as a lint), but if that doesn't work out all the regression we found were relatively "simple" cases that can probably be taken advantage of (if need be) to lint a subset of the actual cases we'd break with this PR

edit: see compiler-errors' comment, I'm not so convinced this will be possible to FCW anymore and will likely investigate improving the diagnostics here. I've already filed PRs to the affected crates to migrate them over to a transmute to avoid the breakage if this lands

compiler-errors · 2025-02-27T05:43:05Z

I was thinking earlier that it may be possible to implement a lint to detect, but it seems to me that MIR borrowck is not equipped to implement such a lint.

Specifically, it seems near impossible to answer whether a region outlives constraint (like, 'a: 'b) would not hold in a way that doesn't actually commit to that constraint, at least not without tons of false positives based on how NLL computes lower bounds for all of the regions it deals with in the MIR.

To fix this would require some significant engineering effort to refactor how NLL processes its region graph to make it easier to clone and reprocess with new constraints.

…uto_to_object-hard-error, r=oli-obk Make `ptr_cast_add_auto_to_object` lint into hard error In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting. We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us. It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this. r? ghost cc `@adetaylor` `@Darksonn` `@BoxyUwU` `@RalfJung` `@compiler-errors` `@oli-obk` `@WaffleLapkin` Related: - rust-lang#135881 - rust-lang#136702 - rust-lang#136776 Tracking: - rust-lang#127323 - rust-lang#44874 - rust-lang#123430

…uto_to_object-hard-error, r=oli-obk Make `ptr_cast_add_auto_to_object` lint into hard error In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting. We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us. It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this. r? ghost cc ``@adetaylor`` ``@Darksonn`` ``@BoxyUwU`` ``@RalfJung`` ``@compiler-errors`` ``@oli-obk`` ``@WaffleLapkin`` Related: - rust-lang#135881 - rust-lang#136702 - rust-lang#136776 Tracking: - rust-lang#127323 - rust-lang#44874 - rust-lang#123430

…uto_to_object-hard-error, r=oli-obk Make `ptr_cast_add_auto_to_object` lint into hard error In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds. This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting. We considered just making this a hard error, but opted against it at that time due to breakage found by crater. This breakage was mostly due to the `anymap` crate which has been a persistent problem for us. It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`. So let's see about making a hard error of this. r? ghost cc ```@adetaylor``` ```@Darksonn``` ```@BoxyUwU``` ```@RalfJung``` ```@compiler-errors``` ```@oli-obk``` ```@WaffleLapkin``` Related: - rust-lang#135881 - rust-lang#136702 - rust-lang#136776 Tracking: - rust-lang#127323 - rust-lang#44874 - rust-lang#123430

BoxyUwU · 2025-08-24T16:43:35Z

r? lcnr

BoxyUwU · 2025-08-24T16:43:51Z

@rfcbot resolve needs FCP proposal

bors · 2025-08-25T14:12:18Z

☔ The latest upstream changes (presumably #145844) made this pull request unmergeable. Please resolve the merge conflicts.

lcnr · 2025-08-28T13:15:39Z

Chatting about this with @BoxyUwU, I've now got the following thoughts here, any inaccuracies are my own :3

There are generally 2 things you can do with trait objects which depend on their vtable:

upcast safety: upcasting to a super trait needs the trait object to actually have an entry pointing to the super trait vtable
dispatch safety: calling methods requires that the trait impl used to create the vtable actually applies for the currnet trait ref of the trait object. I.e. if an impl only applies for Trait<'a> then using that impl as a vtable for a method call on dyn Trait<'static> is unsound

We already require wide pointers to be valid for upcasting on stable, they have to be upcast safe. This means raw pointer casts must not change the const and type arguments of trait objects.

We don't yet require raw pointers to be dispatch safe but want to do so in this FCP. This requires forbidding the addition of auto traits (already stable), changing lifetimes of the trait object (already stable), and changing the lifetime bound of the trait object (this FCP).

Why require raw pointers to be dispatch safe

If we require raw pointers to be dispatch safe we don't need separate notions of upcast safety and dispatch safety, so that's nice. I doubt we'd decide to remove upcast safety requirements by now.

DispatchFromDyn is just sound:tm:, we can dispatch on raw pointers without any soundness concerns

Why not have that requirement

It feels weird :3 I want to be able to go "I actually know the underlying value outlives some specific lifetime and should be able to use an ordinary cast for this". E.g. playground.

We could instead make the impl of DispatchFromDyn unsafe/have some other way to introduce the safety requirement that the given user defined pointer is dispatch safe.

My personal vibe

I am personally still unsure what to prefer, but would have ideally had exactly this decision while we've stabilized trait upcasting as this decision is influenced by the fact that pointers already have to be upcast safe.

With this, requiring them to be dispatch safe as well seems reasonable enough. I think changing MIR borrowck to support forward compat warnings like this would be desirable, but a significant effort the first time we do it. So I think landing this without one is fine.

@rfcbot reviewed

Darksonn · 2025-08-28T14:40:11Z

@lcnr I pretty much agree with that. Here's how I would characterize it:

The safety requirement of a *const dyn Trait for its metadata can be one of three things:

The vtable pointer must be non-null but can otherwise be anything.
The vtable pointer must point at a vtable for Trait, and the entries in that vtable used by trait upcasting must be valid for use with Trait, but other entries of the vtable can be invalid.
The vtable pointer must point at a vtable for Trait, and all entries of the vtable are required to be valid for use with Trait.

Trait upcasting moved from 1 to 2. This FCP moves from 2 to 3.

BoxyUwU · 2025-09-29T15:16:29Z

@rfcbot resolve can we do a FCW

I get the impression that people don't seem too concerned about landing this without an FCW and I think it'll be a while before I can get around to looking into if we even can

rust-rfcbot · 2025-09-29T15:16:38Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rust-rfcbot · 2025-10-09T15:21:37Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

lcnr · 2025-10-13T08:59:57Z

Given the breakage, I would try to merge this right after the next beta cutoff to have the full 6 weeks on nightly

lcnr · 2025-10-13T09:00:49Z

compiler/rustc_borrowck/src/diagnostics/region_errors.rs

+            {
+                diag.span_note(
+                    constraint.span,
+                    format!("raw pointer casts of trait objects do not cast away lifetimes"),


Suggested change

format!("raw pointer casts of trait objects do not cast away lifetimes"),

format!("raw pointer casts of trait objects must not extend lifetimes"),

maybe? "cast away" sounds weird

lcnr · 2025-10-13T09:02:09Z

compiler/rustc_borrowck/src/type_check/mod.rs

+                                    // Trait parameters are Invariant, the only part that actually has subtyping
+                                    // here is the lifetime bound of the dyn-type.
+                                    //
+                                    // For example in `dyn Trait<'a> + 'b <: dyn Trait<'c> + 'd`  we would require
+                                    // that `'a == 'c` but only that `'b: 'd`.
+                                    //
+                                    // We must not allow freely casting lifetime bounds of dyn-types as it may allow
+                                    // for inaccessible VTable methods being callable: #136702
+                                    //
+                                    // We don't enforce this for casts of principal-less dyn types as their VTables do
+                                    // not contain any functions with `Self: 'a` bounds that could start holding after
+                                    // a pointer cast.
+                                    //
+                                    // We also don't enforce this for casts of pointers to pointers to dyn types. E.g.
+                                    // `*mut *mut dyn Trait + 'a -> *mut *mut dyn Trait + 'static` is allowed. This is
+                                    // fine because there is no actual VTable in play.


Suggested change

// Trait parameters are Invariant, the only part that actually has subtyping

// here is the lifetime bound of the dyn-type.

//

// For example in `dyn Trait<'a> + 'b <: dyn Trait<'c> + 'd` we would require

// that `'a == 'c` but only that `'b: 'd`.

//

// We must not allow freely casting lifetime bounds of dyn-types as it may allow

// for inaccessible VTable methods being callable: #136702

//

// We don't enforce this for casts of principal-less dyn types as their VTables do

// not contain any functions with `Self: 'a` bounds that could start holding after

// a pointer cast.

//

// We also don't enforce this for casts of pointers to pointers to dyn types. E.g.

// `*mut *mut dyn Trait + 'a -> *mut *mut dyn Trait + 'static` is allowed. This is

// fine because there is no actual VTable in play.

// Trait parameters are invariant, the only part that actually has subtyping

// here is the lifetime bound of the dyn-type.

//

// For example in `dyn Trait<'a> + 'b <: dyn Trait<'c> + 'd` we would require

// that `'a == 'c` but only that `'b: 'd`.

//

// We must not allow freely casting lifetime bounds of dyn-types as it may allow

// for inaccessible VTable methods being callable: #136702

//

// We don't enforce this for casts of principal-less dyn types as their VTables do

// not contain any functions with `Self: 'a` bounds that could start holding after

// a pointer cast.

//

// We also don't enforce this for casts of pointers to pointers to dyn types. E.g.

// `*mut *mut dyn Trait + 'a -> *mut *mut dyn Trait + 'static` is allowed. This is

// fine because there is no actual VTable in play.

I feel like allowing this for principal-less trait objects is quite inconsistent :< what's the additional breakage when always checking this, even if there are only auto traits

What is meant by "principal-less" here?

this comment https://github.com/rust-lang/rust/pull/136776/files/a3d0dac17975722f9a2bb2e74397d3d1bacd4e52#r2011163243

So this is about casting dyn Send + 'short to dyn Send + 'long? I'm not convinced there's any reason to have a special case in the language for that particular case.

Allowing this behind a pointer indirection is also quite strange. Sure, *mut *mut dyn Trait + 'a has no vtable, but it points to a vtable, and after the cast we'll be using that vtable in a different way.

I don't think the pointer indirection case is strange. That's just casting *mut A to *mut B for two different sized types A,B.

Ah, fair, I forgot for a second that we allow arbitrary casts on raw pointers.^^

I feel like allowing this for principal-less trait objects is quite inconsistent

I agree with u 🤔 I guess this would imply that we never have unconditional vtable methods that depend on lifetimes. E.g. sticking a type_id fn in all vtables like we do for size_of. I've no idea what the additional breakage is like. I can check this for auto-trait only dyn-types and do a second crater run (which will also detect any additional cases in the wild since the last one...)

please do ❤️

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 Feb 9, 2025

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 9, 2025

Auto merge of rust-lang#136776 - BoxyUwU:forbid_object_lifetime_casts…

44f3504

…, r=<try> [WIP] Forbid object lifetime changing pointer casts Fixes rust-lang#136702 r? `@ghost`

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 9, 2025

compiler-errors mentioned this pull request Feb 10, 2025

arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated #136702

Open

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Feb 11, 2025

traviscross mentioned this pull request Feb 11, 2025

Make ptr_cast_add_auto_to_object lint into hard error #136764

Merged

traviscross added the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 12, 2025

ojeda mentioned this pull request Feb 12, 2025

Rust unstable features needed for the kernel Rust-for-Linux/linux#2

Open

nikomatsakis mentioned this pull request Feb 20, 2025

Getting Rust for Linux into stable Rust: language features rust-lang/rust-project-goals#116

Open

53 tasks

traviscross mentioned this pull request Mar 4, 2025

Tracking issue for RFC 3519: arbitrary_self_types #44874

Open

18 tasks

BoxyUwU force-pushed the forbid_object_lifetime_casts branch from cfa1e3a to ccf0f1e Compare August 24, 2025 15:53

This comment has been minimized.

Sign in to view

BoxyUwU force-pushed the forbid_object_lifetime_casts branch from ccf0f1e to 1ba8d9d Compare August 24, 2025 16:27

BoxyUwU added 2 commits August 24, 2025 17:37

Forbid object lifetime changing pointer casts

f20e0c7

Custom diagnostics

2209f3e

This comment has been minimized.

Sign in to view

BoxyUwU force-pushed the forbid_object_lifetime_casts branch from 1ba8d9d to 2209f3e Compare August 24, 2025 16:39

tidy

a3d0dac

BoxyUwU changed the title ~~[WIP] Forbid object lifetime changing pointer casts~~ Forbid freely casting lifetime bounds of dyn-types Aug 24, 2025

BoxyUwU marked this pull request as ready for review August 24, 2025 16:43

rustbot assigned lcnr Aug 24, 2025

lcnr added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 17, 2025

rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Sep 29, 2025

Darksonn mentioned this pull request Oct 9, 2025

Tracking issue for RFC 3621: derive(CoercePointee) #123430

Open

6 tasks

rustbot mentioned this pull request Oct 9, 2025

Tracking issue for release notes of #136776: Forbid freely casting lifetime bounds of dyn-types #147530

Open

lcnr reviewed Oct 13, 2025

View reviewed changes

	format!("raw pointer casts of trait objects do not cast away lifetimes"),
	format!("raw pointer casts of trait objects must not extend lifetimes"),

Forbid freely casting lifetime bounds of dyn-types #136776

Are you sure you want to change the base?

Forbid freely casting lifetime bounds of dyn-types #136776

Conversation

BoxyUwU commented Feb 9, 2025 • edited by traviscross Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Breakage

Uh oh!

BoxyUwU commented Feb 9, 2025

Uh oh!

bors commented Feb 9, 2025

Uh oh!

bors commented Feb 9, 2025

Uh oh!

BoxyUwU commented Feb 9, 2025

Uh oh!

craterbot commented Feb 9, 2025

Uh oh!

craterbot commented Feb 10, 2025

Uh oh!

craterbot commented Feb 11, 2025

Uh oh!

RalfJung commented Feb 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

traviscross commented Feb 12, 2025

Uh oh!

tmandry commented Feb 19, 2025

Uh oh!

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

Uh oh!

Uh oh!

BoxyUwU commented Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

compiler-errors commented Feb 27, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

BoxyUwU commented Aug 24, 2025

Uh oh!

BoxyUwU commented Aug 24, 2025

Uh oh!

bors commented Aug 25, 2025

Uh oh!

lcnr commented Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why require raw pointers to be dispatch safe

Why not have that requirement

My personal vibe

Uh oh!

Darksonn commented Aug 28, 2025

Uh oh!

BoxyUwU commented Sep 29, 2025

Uh oh!

rust-rfcbot commented Sep 29, 2025

Uh oh!

rust-rfcbot commented Oct 9, 2025

Uh oh!

lcnr commented Oct 13, 2025

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!

Choose a reason for hiding this comment

Uh oh!

RalfJung Oct 13, 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

BoxyUwU commented Feb 9, 2025 •

edited by traviscross

Loading

RalfJung commented Feb 11, 2025 •

edited

Loading

traviscross commented Feb 19, 2025 •

edited

Loading

BoxyUwU commented Feb 26, 2025 •

edited

Loading

lcnr commented Aug 28, 2025 •

edited

Loading

RalfJung Oct 13, 2025 •

edited

Loading

BoxyUwU Oct 13, 2025 •

edited

Loading