Ensure SMIR internal function is safe
#120120
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The internal function was unsound, it could cause UB in rare cases where the user inadvertly stored the returned object in a location that could outlive the TyCtxt. In order to make it safe, we now take a type context as an argument to the internal fn, and we ensure that interned items are lifted using the provided context. Thus, this change ensures that the compiler can properly enforce that the object does not outlive the type context it was lifted to.
rustbot
added
S-waiting-on-review
|
@bjorn3 can you please see if that makes sense? Thanks! |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 21, 2024
…nval Make stable_mir::with_tables sound See the first commit for the actual soundness fix. The rest is just fallout from that and is entirely safe code. Includes most of rust-lang#120120 The major difference to rust-lang#120120 is that we don't need an unsafe trait, as we can now rely on the type system (the only unsafe part, and the actual source of the unsoundness was in `with_tables`) r? `@celinval`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 21, 2024
…nval Make stable_mir::with_tables sound See the first commit for the actual soundness fix. The rest is just fallout from that and is entirely safe code. Includes most of rust-lang#120120 The major difference to rust-lang#120120 is that we don't need an unsafe trait, as we can now rely on the type system (the only unsafe part, and the actual source of the unsoundness was in `with_tables`) r? `@celinval`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 22, 2024
Rollup merge of rust-lang#120128 - oli-obk:smir_internal_lift, r=celinval Make stable_mir::with_tables sound See the first commit for the actual soundness fix. The rest is just fallout from that and is entirely safe code. Includes most of rust-lang#120120 The major difference to rust-lang#120120 is that we don't need an unsafe trait, as we can now rely on the type system (the only unsafe part, and the actual source of the unsoundness was in `with_tables`) r? `@celinval`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
rustc_smir::rustc_internal::internalfunction was unsound. It could cause UB in rare cases where the user inadvertently stored the returned object in a location that could outlive the TyCtxt.In order to make it safe, we now take a type context as an argument to the internal function, and we ensure that interned items are lifted using the provided context.
Thus, this change ensures that the compiler can properly enforce that the object does not outlive the type context it was lifted to.
Call-outs
Liftimplementation toLayoutsince it is directly interned, but it didn't have aLiftimplementation.'tcxlifetime intotables. In cases where the code is reachable viastable()function call, there is no guarantee that tables won't outlive the object being stored.r? @oli-obk