Use uninit checking from rustc #10520
Merged
Conversation
This file contains hidden or 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
|
r? @Alexendoo (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
the
S-waiting-on-review
Noratrieb
commented
Mar 18, 2023
Noratrieb
force-pushed
the
uninit
branch
2 times, most recently
from
833a265 to
4edb4d1
Compare
Alexendoo
reviewed
Mar 18, 2023
Noratrieb
commented
Mar 19, 2023
| // edge case: For now we lint on empty arrays | ||
| let _: [u8; 0] = unsafe { MaybeUninit::uninit().assume_init() }; | ||
|
|
||
| // edge case: For now we accept unit tuples |
There was a problem hiding this comment.
I also changed this comment because this isn't really a "for now", ZSTs are simply valid here.
rustc has proper heuristics for actually checking whether a type allows being left uninitialized (by asking CTFE). We can now use this for our helper instead of rolling our own bad version with false positives.
Alexendoo
approved these changes
Mar 21, 2023
|
Great, thanks! @bors r+ |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
|
I believe we've found a false-positive for this here. |
|
Uh, that's because this is a polymorphic type and we are conservative around polymorphic types and always say that they are wrong. |
This was referenced Mar 26, 2023
1 task
bors
added a commit
that referenced
this pull request
Mar 29, 2023
In uninit checking, add fallback for polymorphic types After #10520, we always assumed that polymorphic types do not allow to be left uninitialized. But we can do better, by peeking into polymorphic types and adding a few special cases for going through tuples, arrays (because the length may be polymorphic) and blanket allowing all unions (like MaybeUninit). fixes #10551 changelog: [uninit_vec]: fix false positive for polymorphic types changelog: [uninit_assumed_init]: fix false positive for polymorphic types
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.
rustc has proper heuristics for actually checking whether a type allows being left uninitialized (by asking CTFE). We can now use this for our helper instead of rolling our own bad version with false positives.
I added this in rustc in rust-lang/rust#108669
Fix #10407
changelog: [
uninit_vec]: fix false positiveschangelog: [
uninit_assumed_init]: fix false positives