Forbid freely casting lifetime bounds of dyn-types #136776
Conversation
rustbot
added
S-waiting-on-review
|
@bors try |
…, r=<try> [WIP] Forbid object lifetime changing pointer casts Fixes rust-lang#136702 r? `@ghost`
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
Most of these are on github; in terms of crates.io regressions all we have is:
Overall, 142 regressions are caused by EDIT: Ah, there's also |
traviscross
added
the
I-lang-nominated
|
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. |
|
@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. |
|
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 cc @rust-lang/lang |
|
@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 |
|
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, 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
This comment has been minimized.
This comment has been minimized.
BoxyUwU
force-pushed
the
forbid_object_lifetime_casts
branch
from
d4df18c to
5a4d526
Compare
BoxyUwU
added
S-waiting-on-review
|
☔ The latest upstream changes (presumably #148823) made this pull request unmergeable. Please resolve the merge conflicts. |
BoxyUwU
force-pushed
the
forbid_object_lifetime_casts
branch
from
06e4c91 to
9fcb8bc
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
BoxyUwU
force-pushed
the
forbid_object_lifetime_casts
branch
from
9fcb8bc to
ee48e3f
Compare
|
missing a final comment, r=me after |
BoxyUwU
force-pushed
the
forbid_object_lifetime_casts
branch
from
f84233e to
85aeb4f
Compare
|
@bors r+ rollup=never |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 377656d (parent) -> 198328a (this PR) Test differencesShow 8 test diffsStage 1
Stage 2
Additionally, 2 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 198328ad7960b1bece0dc48496bff6c62dd5d339 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (198328a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -0.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -3.5%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 471.42s -> 471.708s (0.06%) |
20 participants
Fixes #136702
Reference PR:
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 + 'ato*mut dyn Trait + 'bpasses with no requirements on'aor'b. Under this PR we now require'ato outlive'b.Even though the pointee of
*mutpointers is considered to be invariant, we still use subtyping rather than equality. This mirrors how we support coercing&mut dyn Trait + 'ato&mut dyn Trait + 'bwhile requiring only'a: 'b. I believe this coercion is sound as there is no way for safe code tomem::swaptwodyn 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 + 'ais allowed to be casted to*mut *mut dyn Trait + 'bwith no requirements on'aor '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: 'bunder 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-2/index.html
The majority of the breakage is caused by the
metricscrate with 142 of the regressions, and themaycrate with 14 of the regressions. Themetricscrate has been fixed and has backported the fix to previous versions of the crate that were also affected. Themaycrate has also been fixed.PRs against affected crates have been opened and can be seen here:
There were six regressions I've not filed PRs against:
r? @ghost