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-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

"must not" sounds like "you can do it but you shouldn't". How about "can't extend lifetimes"?

I learned in school that "must not" means "is not allowed to". But maybe it doesn't universally have that meaning?

Well... It does mean that it's not allowed to do it. But to me "not allowed to" brings forward the wrong connotations compared to "can't"/"not able to"/"not possible" in the specific case of a compiler error message.

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.

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 ❤️

Is there anything I can do to help here?

If you'd be able to checkout this PR and maybe rebase it then make a commit to check for the case where the target type has no principal trait and if so push an outlives requirement that the lifetime of the source trait object outlives the lifetime of the target trait object, that would be helpful 🤔 then its just a matter of queueing a crater run and checking it's not got more regressions than the previous one

rustbot · 2025-11-21T14:48:35Z

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.

Darksonn · 2025-11-21T15:49:17Z

@bors try

Forbid freely casting lifetime bounds of dyn-types

rust-bors · 2025-11-21T18:10:57Z

☀️ Try build successful (CI)
Build commit: 7424ce9 (7424ce9ff9baac3e9d9f5dd3c85828cddea0134d, parent: e22dab387f6b4f6a87dfc54ac2f6013dddb41e68)

Darksonn · 2025-11-21T18:44:12Z

@craterbot check

craterbot · 2025-11-21T18:44:42Z

👌 Experiment pr-136776-1 created and queued.
🤖 Automatically detected try build 7424ce9
🔍 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

BoxyUwU · 2025-11-22T00:37:03Z

compiler/rustc_borrowck/src/type_check/mod.rs

+                            && src_tty.principal().is_none()
+                            && dst_tty.principal().is_none()


@Darksonn I think this currently means that casting something like: *mut dyn Trait + Send + 'a to *mut Send + 'b won't check 'a: 'b. We ought to drop the src_tty.principal().is_none() check here, unless I'm misreading this code :)

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

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

BoxyUwU added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. labels Oct 21, 2025

BoxyUwU and others added 3 commits November 21, 2025 12:15

Forbid object lifetime changing pointer casts

5895e03

Add test for principal-less cast

634f912

Add check for non-principal trait casts

d525233

Darksonn force-pushed the forbid_object_lifetime_casts branch from a3d0dac to d525233 Compare November 21, 2025 14:48

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Nov 21, 2025

Auto merge of #136776 - BoxyUwU:forbid_object_lifetime_casts, r=<try>

7424ce9

Forbid freely casting lifetime bounds of dyn-types

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 21, 2025

BoxyUwU commented Nov 22, 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"),

		&& src_tty.principal().is_none()
		&& dst_tty.principal().is_none()

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!

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!

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!

BoxyUwU 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

Uh oh!

BoxyUwU Nov 21, 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!

rustbot commented Nov 21, 2025

Uh oh!

Darksonn commented Nov 21, 2025

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

BoxyUwU Oct 13, 2025 •

edited

Loading

BoxyUwU Nov 21, 2025 •

edited

Loading