[WIP] Forbid object lifetime changing pointer casts #136776

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

Fixes #136702

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

Manishearth · 2025-03-27T06:05:50Z

From the perspective of an unsafe reviewer (and someone who tries to teach others to unsafe review), I'd like to state a strong opposition to forbidding this in safe code only and allowing it in unsafe, thereby introducing a new source of UB to as casts.

So far as casts are UB based on the usage of their results, not based on the cast themselves¹. They are not easy to review, especially with inferred types (and such), but ultimately you can kinda go "well we turned a thingy into a thangy and are now degreebling it, which is safe to do to the original type in this context". This introduces a new, much trickier, modality to the review.

Currently, what is the actual unsafe operation is a major and tricky task when reviewing unsafe code. Fortunately, it mostly boils down to "look at the function calls" and "look at the *s", and in rarer cases "look at modifications of a MUTABLE_STATIC" and "look at field accesses". Multiple people have talked about teachability already: this new source is subtler than those, non-obvious, and kinda hard to notice in code. This is going to be a source of problems.

I definitely feel heard by @RalfJung's comment here:

This is quite dubious. We're retroactively attaching more safety obligations to an existing operation, and then if there's UB somewhere we tell you its your fault since you wrote unsafe and thereby promised you upheld the safety obligation that didn't even exist yet when you wrote the code?

I think that's not a good precedent to set at all.

And by @compiler-errors's comment:

This definitely complicates that teachability, and IMO this is a pretty drastic new behavior to have to introduce just to avoid crate breakage from something we only recently started to allow, and from the type system perspective I am pretty inclined to push back on this proposal from a maintenance perspective.

Yep, this feels rather drastic to me as an unsafe reviewer .

I like @nikomatsakis' axioms here, and I'll note that making this UB is breakage from an unsafe-writer's POV too, even if it doesn't cause compilation failures, and I'd argue that that's worse since there's no way to detect it.

Minimizing the position on @nikomatsakis' breakage ladder should account for this type of breakage too, it shouldn't just be about "which code still compiles".

This is the judgment call. metrics is a widely used crate, and personally I think breaking user code unnecessarily so we can ship a high priority feature is not a great look. There was some discussion that each affected crate might release a fixed version but that new releases might not be semver compatible with all the existing ones people are using, and that upstreaming fixes (which is a good thing we should continue doing) is not a panacea even, if we accept that users will need to cargo update. Unfortunately we don't have a standard yardstick to use to measure crates.io breakage by; I suspect people are using various heuristics and perhaps a slight change in those heuristics can lead to a different opinion on this judgment call. But this is the one we had consensus on in the meeting.

@tmandry

It feels like talking about the semver issue feels premature unless we know that the metrics crate does not want to do backports and stuff: do we know that?

When it comes to these kinds of breakages I feel like there's a lot of value in negotiating with our users. Some users have legitimate needs and will say no to stuff like this, but quite often the answer can be "...yeah, okay, not ideal but we can work with that". As a crate maintainer I've had to do that often enough, from both sides of the equation.

I understand that this doesn't cover private crates, which is a risk, but this is a problem that can be attacked from multiple angles, including the FCW.

I wanted to note again that I don't think it will be possible to implement such a lint in a way that doesn't either have too many false positives (e.g. triggers on every 'static raw wide pointer cast) or too many false negatives (e.g. doesn't detect the breakage that we want to lint here).

I do feel like this is a tradeoff that one can make a call on: either choice at least gives people something to work with. To me it feels like some pain now is worth avoiding perpetual pain in the long run.

Also, perhaps I'm missing something: but the FCW is being talked about for the situation where this becomes a hard error, yes? If it's possible to hard error, it should be possible to FCW for that case with no false negatives, no?

One thing I'll add, looking holistically at this: personally I don't particularly enjoy replacing as with transmute
(I think transmute is too powerful and it's nice to be able to narrow it down to a specific, clear purpose), it would probably be nice to have an unsafe macro or something that narrowly does a lifetime pointer cast, but that might be too niche an API. Not actually trying to propose that here.

Not fully clear on the situation here with provenance though. I know ptr-to-int transmutes are UB or otherwise verboten in const, but the as cast is forbidden by ↩

RalfJung · 2025-03-27T07:43:53Z

@tmandry

An argument was also made that as casts on pointers are strictly more powerful than transmuting a value because they allow changing the size of the pointee, and it would be nice to preserve the property that as pointer casts are strictly more powerful than transmute.

I don't understand what you mean by this. I can transmute *const dyn Send to *const dyn Debug but I cannot do an as cast here. So in which sense are as casts strictly more powerful on pointers? Also I can of course transmute *const u32 to *const u8, i.e., transmute can change the size of the pointee.

Transmute cannot change the size of the pointer, e.g. *const i32 to *const dyn Send. Is that what you mean? But then the claim that as is strictly more powerful is still wrong since as on wide ptrs ensures that the "unsized tail" remains of the same shape.

@Manishearth

So far as casts are UB based on the usage of their results, not based on the cast themselves

This property is preserved. A bad as cast violates a library/"safety" invariant, which means that future safe operations can cause UB. But the bad cast itself cannot cause UB.

The difference to before is that so far as casts could cause UB only based on unsafe usage of their results. With the proposed change, even safe usage (of unsafe casts) can cause UB.

BoxyUwU · 2025-03-27T19:44:51Z

I'll try not to re-cover what other people have already commented, e.g. feelings about teachability here, or pointer casts not being strictly more powerful (or equal to) transmutes.

First, reading the lang meeting minutes and the summarizing comment here I get the impression that lang is making decisions under the belief that writing *const dyn Trait means *const dyn Trait + 'static in all circumstances. This is not true.

In item signatures we have the dyn type lifetime default rules that do give this behaviour, e.g. static FOO: *const dyn Trait = ...; is equivalent to *const dyn Trait + 'static. However, in bodies (e.g. the initializer of a static, or inside the { ... } of a function), elided lifetimes of dyn types are simply unconstrained lifetimes that are inferred by the borrow checker. Example:

fn foo<T: Trait>(ptr: *const T) {
    let a: *const dyn Trait = ptr;
}

This currently compiles on stable and will continue to do so under this PR. If the type annotation on the let statement meant *const dyn Trait + 'static then this would not compile even on stable.

I am somewhat confused by the proposal to start linting on code. The exact details of what we're supposed to lint on are unclear to me, especially given the prior context of having already ruled out being able to do a FCW. Having read the meeting notes my understand is that lang is considering a lint that forbids eliding dyn type lifetimes altogether in as casts?

For example that the following would emit a lint:

fn foo<T: Trait>(ptr: *const T) {
    ptr as *const dyn Trait;
}

I would expect this to have a lot of false positives. I also don't believe this really helps alleviate the footguns involved with these pointer casts (which seemed to be a big point of focus in the meeting notes, that this removes a footgun). Even when explicitly writing out the lifetimes involved you can just write lifetimes that make it seem like no real lifetime changing has occurred.

Taking the example from the lang meeting notes:

fn foo(output: &dyn Write) {
  /* ... */
  unsafe { output as *const (dyn Write + 'static) as *mut (dyn Write + 'static) };
  /* ... */
}

This example still seems like a footgun, the explicitly written lifetime bounds almost make it worse as you could easily believe that the pointee of output lives for 'static and that we then perform a pointer cast which does not change the lifetime bound.

In order to avoid a footgun here the type of output with the lifetime bound written explicitly needs to be present so that you can see the source and target types of the cast. e.g. my_ref as &(dyn Trait + 'a) as *const dyn Trait + 'static doesn't seem like a footgun as you can tell that a cast from + 'a to + 'static is occuring.

I am also unclear on where lang stands in regards to breaking such unsafe code over an edition. The summary comment here was not particularly clear, and reading the meeting notes I have been given the impression that no real consensus was arrived at and that the hypothetical lint obviates any need to break this unsafe code.

I am not sure if things have changed for lang now given my previous statements about footguns and dyn-type elision rules.

Before going through with this I would like for lang to fully commit to either supporting such casts as an actual language feature, or only as a migration hack with a commitment to break it going forward across the 2025 edition (with the understanding that it may not be possible to FCW or auto-fix).

Generally I would like to avoid going forward with this with a vague handwaving of "we could potentially break this over an edition" to assuage concerns of teachability/etc, and then potentially wind up with lang deciding not to do so.

On the general consistency of pointer casts here. Lang has already forbidden casting *const dyn Trait to *const dyn Trait + Send, and have also already forbidden casting *const dyn Trait<'a> to *const dyn Trait<'b> (or even *const dyn Trait<T> to *const dyn Trait<U>).

If lang wishes to extend the power of as casts in unsafe code to be able to do more "transmute like" casts as a language feature, then I would expect us to also allow these arbitrary casts of dyn types. Is this something lang is on board with?

On the other hand if this is only intended as a migration strategy then this inconsistency seems fine to me as we expect all code to either be legacy (i.e. no longer maintained) or updated to a newer edition where there is no inconsistency.

Finally, reading the meeting notes I see that there were parallels drawn between raw pointer derefs being the same syntax as derefing references and how one is safe and the other not.

Admittedly I do see the parallel here but I think it's worth pointing out that it is significantly easier to determine whether one is dereferencing a pointer or reference, in comparison to determining whether a lifetime has been extended. I think lang is aware of this hence the discussion of the lint and avoiding footguns? I think this is worth revisiting in light of previous statements about footguns/the lint.

I would also like to note that r-a currently has the ability to highlight unsafe operations in a specific colour to make it more clear when safety invariants are introduced in unsafe code. I don't know how well that can be supported with this change where all as casts of pointers to dyn-types in unsafe blocks are sometimes morally-unsafe but only determinable by the specific lifetimes in play.

Do we expect r-a to be able to figure this out or just conservatively consider all of these as casts to be unsafe operations? Similar to the previous section of my comment, I don't think this is much of a problem if this change is only done as a migration method and broken over an edition. It's probably fine if legacy codebases have "overly liberal" application of "this operation is unsafe" highlighting.

I generally find it hard to go along with the idea that its "just" allowing a new operation to be performed inside of unsafe code rather than "changing semantics/disabling checks" when both humans and tooling is going to struggle to even distinguish these two different operations. This to the extent that the compiler impl would literally be to unconditionally generate the "unsafe transmute cast" operation in unsafe blocks rather than the checked kind.

I think the fact that there is ~no world in which the compiler impl will align with this mental model of "its a new operation allowed in unsafe" should be a good signal that it's not the right mental model.

BoxyUwU · 2025-03-27T19:49:13Z

Separately from my previous comment I want to just say that the metrics author(s?) seem amenable to backporting the fix to previous releases allowing crates that depend on older-semver-incompatible version to painlessly upgrade. This crate is by far the largest source of regressions of this change other than the may crate.

The may crate however does not have its casts already present in an unsafe block so would not be affected by this migration strategy of "allow it in unsafe blocks". With backported versions of metrics released I think the outcome of insta-breaking would be a lot smaller/more palatable, or atleast the benefit of continuing to allow this in unsafe code is significantly smaller as users of metrics would already have a trivial path to being unbroken.

(If you look at the crater regressions there are maybe a dozen due to may but maybe a hundred due to metrics)

workingjubilee · 2025-03-27T21:09:56Z

@Veykril Could you weigh in on the technical feasibility of both detecting this new class of unsafe-but-only-when-lifetime-changing as casts, using r-a's understanding of how Rust code works, and emitting the right highlighting suggestions to editors to identify this for users?

tmandry · 2025-03-27T23:40:07Z

Thanks for the feedback everyone. I was the one primarily pushing to avoid unnecessary breakage in this case. That is conditional on the feasibility and maintainability of a solution, and @compiler-errors makes a compelling case that it would be neither. No one thought we were proposing changes to MIR borrow check! @BoxyUwU may be able to confirm/deny if that is what she had in mind.

I think we've heard enough to convince me that this is not a path worth going down now. It sounds like the lint mitigation was based on some faulty assumptions. Upon reflection, I agree with @BoxyUwU that we should have consensus within the lang team to walk this safe/unsafe difference back over an edition before releasing it. Deciding this is infeasible or a maintenance burden, or being convinced (as others seem to be) that the breakage is very minimal, would be enough as well.

In this particular case I think the breakage is unfortunate but workable, so I am okay to move forward. I don't speak for the rest of the lang team in this comment, but no one spoke up about wanting to avoid the breakage as much as I did.

@Manishearth You mentioned an FCW; my understanding has been that an FCW in this case is infeasible. I do agree with your assertion that this would make unsafe reviews harder.

IMO this is a pretty drastic new behavior to have to introduce just to avoid crate breakage from something we only recently started to allow

@compiler-errors That wasn't my understanding from the discussion, which included a 6yr old version of diesel. Was that relying on this as an unstable feature until recently, or what am I missing?

compiler-errors · 2025-03-28T02:34:37Z

@tmandry: I guess I was a bit misled when I said we only recently started to allow this behavior. What I should have said is that we only recently made this behavior more relaxed beginning with #113262.

That PR made casts where nothing but the lifetime was changing work, i.e. expr as *const dyn Tr + '_ as *const dyn Tr + 'static even if expr's type doesn't outlive 'static. That's why most of the regressions are from ~1 year ago or so.

But there are rare cases where this behavior coincidentally worked when there were more than 1 casts chained together and between the two casts more than the lifetime changed in the casted type. That old diesel one is an example. Boxy and I worked out a few examples where this was allowed even pre 1.75 which is when that linked PR landed.

This is the moral equivalent of the diesel example:

trait Tr {}

struct Foo {
    ptr: dyn Tr + 'static
}

fn foo<T: Tr>(x: &dyn Tr) -> *const Foo {
    let x = x as *const dyn Tr as *const Foo;
    x
}

And this is the moral equivalent of the brainfuck one:

trait Tr {}

fn foo<T: Tr>(x: &dyn Tr) -> *mut (dyn Tr + 'static) {
    x as *const dyn Tr as *mut dyn Tr
}

Both of these examples worked before 1.75 because they were emitting something that was a non-trivial pointer cast. But they still are definitely violations of the vtable validity here.

I will note that we're still really funny with what we allow when doing raw pointer casts of wide pointers. For example, this errors today:

trait Tr {}

fn foo<T: Tr>(x: &dyn Tr) -> *const (dyn Tr + 'static) {
    x as *const dyn Tr
}

i.e. it was not fixed by #113262. You could argue that @BoxyUwU's PR here is making the language more consistent by always enforcing the correct lifetimes in wide pointers along these lines :)

Veykril · 2025-03-28T05:20:27Z

@Veykril Could you weigh in on the technical feasibility of both detecting this new class of unsafe-but-only-when-lifetime-changing as casts, using r-a's understanding of how Rust code works, and emitting the right highlighting suggestions to editors to identify this for users?

given rust-analyzer is still completely oblivious to lifetimes in our IRs I'd say very difficult. Though either way that feature is only meant to show what would be erroring if the unsafe block was missing, which reading from this, the as cast wouldn't even do in the first place? (as you said it is more of a new class of unsafe)

traviscross · 2025-03-28T05:34:21Z

On the substance here, we'll obviously take this back up on Wednesday. My estimate is that we're rather likely to readopt the original plan and to "stay the course" on that. We very nearly went that way last Wednesday.

Speaking for myself, I think what's being done here, in terms of making PRs to the affected public projects and working out a diagnostic that guides people in the right direction, is what we need to do, and combined with the soundness arguments we've been making, is sufficient to justify and support this change. I appreciate -- and I know we all on lang appreciate -- the work @BoxyUwU did to make those PRs and is doing to put this all together. It's a nice additional benefit that we apparently only allowed the most likely kinds of this semi-recently and that this probably does make the language more consistent in the way that CE mentioned.

RalfJung · 2025-03-28T07:38:10Z

making PRs to the affected public projects and working out a diagnostic that guides people in the right direction

By "diagnostic" here you refer to the hard error that shows in code this breaks?

@BoxyUwU @compiler-errors how practical is it to give a dedicated diagnostic for this case?

traviscross · 2025-03-28T08:02:05Z

By "diagnostic" here you refer to the hard error that shows in code this breaks?

That's right.

Manishearth · 2025-03-28T23:21:01Z

@Manishearth You mentioned an FCW; my understanding has been that an FCW in this case is infeasible. I do agree with your assertion that this would make unsafe reviews harder.

@tmandry

Maybe I'm missing something, and part of the issue with this thread is that it's not always clear what changes specifically are being talked about.

But for the proposal on the table that is:

Forbid some things entirely in as casts in safe rust
Allow them in unsafe rust but unsafe rust writers need to worry about the precise usage pattern to avoid/trigger UB

It should be instead possible to forbid those things entirely in all as casts, and have an FCW/edition/whatever for them, since if it is possible to forbid a thing it should be possible to use the same mechanism to lint it.

If the FCW for forbidding such casts is impossible to write, then I ask: how are you going to forbid the operation completely in safe Rust as is the lang team's proposal?

@traviscross

On the substance here, we'll obviously take this back up on Wednesday. My estimate is that we're rather likely to readopt the original plan and to "stay the course" on that. We very nearly went that way last Wednesday.

Could you explicitly write down the "original plan"? This thread is rather self referential, the linked comment doesn't specify the plan, it refers to a previous comment which also isn't fully clear.

compiler-errors · 2025-03-28T23:29:13Z

If the FCW for forbidding such casts is impossible to write, then I ask: how are you going to forbid the operation completely in safe Rust as is the lang team's proposal?

Because it amounts to literally running all of borrowck twice. It's not impossible to write, but it's prohibitively difficult to do and would require quite a lot of refactoring. Straight up denying it amounts to a few lines of change, as implemented in the PR today.

traviscross · 2025-03-29T02:31:44Z

Could you explicitly write down the "original plan"?

It's what I went on to say. We do the breaking change along with a diagnostic on the error that tries to point people in the right direction and we make PRs to affected projects.

Manishearth · 2025-03-29T16:25:42Z

@traviscross there are multiple possible breaking changes in this thread, and multiple lints. I don't actually think anyone has precisely defined what is happening so far all in one place, instead referencing previous comments with wording like "the breaking change".

BoxyUwU · 2025-03-29T20:01:49Z

The breaking change is that casting *const dyn Trait + 'a to *const dyn Trait + 'b will now require 'a: 'b to hold, whereas previously these lifetimes were allowed to be entirely unrelated.

Manishearth · 2025-03-30T02:06:59Z

Hmm, from what I recall that specific example is possible to lint against in a late lint pass. There's a lot of talk of MIR borrowck when talking about feasability, maybe I'm missing something, but from clippy experience that seems implementable?

BoxyUwU · 2025-03-30T02:14:00Z

It's not just about that specific example, for the general case you need borrowck to check things like *const dyn Trait + '_ being cast to *const dyn Trait + '_ doesnt wind up doing something equivalent to that example.

Manishearth · 2025-03-30T16:48:03Z

I mean, yes, I understand it's not a simple AST match, but ultimately those are both TyKind::Dynamics, which does still retain the Region`. I can imagine there are a lot of corner case Regions that are not easily compared, but I was under the impression it's possible for the common cases. From digging deeper it seems like it's more complicated than that.

An FCW with a lot of false positives or false negatives is potentially still worth trying, though, if they don't end up triggering often.

RalfJung · 2025-03-31T06:40:07Z

@Manishearth The only part of the compiler that actually knows lifetimes is borrowck. So nothing outside borrowck can implement this lint as there's no way to actually get hold of the two lifetimes that have to outlive each other.

Inside borrowck, the way the hard error is implemented is to add this new constraint to the big sea of constraints that is gathered up during borrowck. Borrowck never explicitly materializes concrete lifetimes, all it does is gather constraints and then check if the constraint system is satisfiable. That makes it impossible to lint since when borrowck fails, it is entirely unclear whether it would have succeeded without that extra constraint.

Manishearth · 2025-03-31T17:28:09Z

Ah, I see. I was under the impression some of this information was available after MIR borrowck, but looking through clippy we don't actually do that. Fair enough.

(I may be operating on a model of things from before MIR borrowck)

traviscross · 2025-04-02T16:30:21Z

We talked about this on the lang call today, and we'd like to unblock this in favor of proceeding with the original plan, which is that we plan to accept the breaking change as originally proposed in this PR subject to PRs being made to affected projects (already done) and an attempt being made to provide a diagnostic along with the hard error that will point people in the right direction on this as best as possible.

When this PR is ready, along those lines, please renominate it for us, and we'll propose lang + types FCP.

@rustbot labels -I-lang-nominated +I-lang-radar

Forbid object lifetime changing pointer casts

d5ebeac

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

93 tasks

nikomatsakis mentioned this pull request Feb 20, 2025

Stabilize tooling needed by Rust for Linux rust-lang/rust-project-goals#116

Open

26 tasks

traviscross mentioned this pull request Mar 4, 2025

Tracking issue for RFC 3519: arbitrary_self_types #44874

Open

16 tasks

traviscross mentioned this pull request Mar 27, 2025

Random musing on the library-level UB casting problem #139036

Closed

traviscross mentioned this pull request Mar 28, 2025

Disregard: Broken attempt at type_id hack on stable Rust with no unsafe #139043

Closed

rustbot added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. labels Apr 2, 2025

[WIP] Forbid object lifetime changing pointer casts #136776

Are you sure you want to change the base?

[WIP] Forbid object lifetime changing pointer casts #136776

Conversation

BoxyUwU commented Feb 9, 2025

BoxyUwU commented Feb 9, 2025

bors commented Feb 9, 2025

bors commented Feb 9, 2025

BoxyUwU commented Feb 9, 2025

craterbot commented Feb 9, 2025

craterbot commented Feb 10, 2025

craterbot commented Feb 11, 2025

RalfJung commented Feb 11, 2025 • edited Loading

traviscross commented Feb 12, 2025

tmandry commented Feb 19, 2025

traviscross commented Feb 19, 2025 • edited Loading

BoxyUwU commented Feb 26, 2025 • edited Loading

compiler-errors commented Feb 27, 2025

Manishearth commented Mar 27, 2025 • edited Loading

Footnotes

RalfJung commented Mar 27, 2025 • edited Loading

BoxyUwU commented Mar 27, 2025

BoxyUwU commented Mar 27, 2025 • edited Loading

workingjubilee commented Mar 27, 2025

tmandry commented Mar 27, 2025

compiler-errors commented Mar 28, 2025 • edited Loading

Veykril commented Mar 28, 2025

traviscross commented Mar 28, 2025 • edited Loading

RalfJung commented Mar 28, 2025

traviscross commented Mar 28, 2025

Manishearth commented Mar 28, 2025

compiler-errors commented Mar 28, 2025

traviscross commented Mar 29, 2025

Manishearth commented Mar 29, 2025

BoxyUwU commented Mar 29, 2025

Manishearth commented Mar 30, 2025

BoxyUwU commented Mar 30, 2025

Manishearth commented Mar 30, 2025

RalfJung commented Mar 31, 2025

Manishearth commented Mar 31, 2025

traviscross commented Apr 2, 2025 • edited Loading

RalfJung commented Feb 11, 2025 •

edited

Loading

traviscross commented Feb 19, 2025 •

edited

Loading

BoxyUwU commented Feb 26, 2025 •

edited

Loading

Manishearth commented Mar 27, 2025 •

edited

Loading

RalfJung commented Mar 27, 2025 •

edited

Loading

BoxyUwU commented Mar 27, 2025 •

edited

Loading

compiler-errors commented Mar 28, 2025 •

edited

Loading

traviscross commented Mar 28, 2025 •

edited

Loading

traviscross commented Apr 2, 2025 •

edited

Loading