-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Runtime checks for occupied niches #624
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. cc @rust-lang/compiler @rust-lang/compiler-contributors |
@rustbot second |
@rustbot label -final-comment-period +major-change-accepted |
Check for occupied niches Implementation of rust-lang/compiler-team#624 r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. --- During implementation, this ran into llvm/llvm-project#68381 r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. --- During implementation, this ran into llvm/llvm-project#68381 r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. --- During implementation, this ran into llvm/llvm-project#68381 r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. --- During implementation, this ran into llvm/llvm-project#68381 r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. --- During implementation, this ran into llvm/llvm-project#68381 r? `@ghost`
Check for occupied niches Implementation of rust-lang/compiler-team#624 Crater run has 62 crates that hit the check, 43 of those are published to crates.io. I see a lot of null function pointers and use of `mem::uninitialized` where the 0x1-filling collides with an enum niche. But that is with full niche checks; checking transmute, plus any place where that we Copy, Move, or Inspect. Such checking is definitely too thorough to be on by default because it is 2x compile time overhead. --- During implementation, this ran into llvm/llvm-project#68381 r? `@ghost`
Proposal
When executing a typed copy where the type contains a niche, the compiler may insert a runtime check that the type's niche(s) are unoccupied. In practical terms, these runtime checks will be inserted strategically in order to minimize runtime overhead (checking that every reference is not null every time they appear on the left side of a MIR assignment statement would have ridiculous overhead).
I have been slowly working on an implementation of this at rust-lang/rust#104862, following my work on #570
Mentors or Reviewers
I do not have any in mind
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: