Skip to content
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

Make non-power-of-two alignments a validity error in Layout #95361

Merged
merged 1 commit into from
Apr 9, 2022

Conversation

scottmcm
Copy link
Member

@scottmcm scottmcm commented Mar 27, 2022

Inspired by the zulip conversation about how Layout should better enforce size <= isize::MAX as usize, this uses an N-variant enum on N-bit platforms to require at the validity level that the existing invariant of "must be a power of two" is upheld.

This was MIRI can catch it, and means there's a more-specific type for Layout to store than just NonZeroUsize.

It's left as pub(crate) here; a future PR could consider giving it a tracking issue for non-internal usage.

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 27, 2022
@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 27, 2022
@scottmcm
Copy link
Member Author

@bors rollup=iffy (I manually crafted a 32-bit stderr, which I could easily have done wrong)

@scottmcm scottmcm added T-libs Relevant to the library team, which will review and decide on the PR/issue. and removed T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 27, 2022
LL | const LAYOUT_INVALID: Layout = unsafe { Layout::from_size_align_unchecked(0x1000, 0x00) };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed at .align_: encountered 0, but expected something greater or equal to 1
LL | const LAYOUT_INVALID_ZERO: Layout = unsafe { Layout::from_size_align_unchecked(0x1000, 0x00) };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed at .align_.0.<enum-tag>: encountered 0x00000000, but expected a valid enum tag
Copy link
Member

@bjorn3 bjorn3 Mar 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error message is not exactly clear about what property the value needs to have.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's ok. It's a best-effort UB check -- the place to look is at the # Safety comment, not the error message.

One gets essentially the same error from things like this too:

pub const BAD_ORDERING: std::cmp::Ordering = unsafe { std::mem::transmute(3_u8) };

So it'll get better here if the error in general gets better for enums, which seems fine for this PR.

@Mark-Simulacrum
Copy link
Member

This feels like overall a good change to me, modulo the one nit -- r=me with that fixed or we can discuss if you disagree.

I would prefer for the commits to all be squashed into one as well.

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 8, 2022
Inspired by the zulip conversation about how `Layout` should better enforce `size < isize::MAX as usize`, this uses an N-variant enum on N-bit platforms to require at the validity level that the existing invariant of "must be a power of two" is upheld.

This was MIRI can catch it, and means there's a more-specific type for `Layout` to store than just `NonZeroUsize`.
@scottmcm
Copy link
Member Author

scottmcm commented Apr 9, 2022

Removed the macro and squashed.

@bors r=Mark-Simulacrum

@bors
Copy link
Contributor

bors commented Apr 9, 2022

📌 Commit fe0c08a has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 9, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Apr 9, 2022
…crum

Make non-power-of-two alignments a validity error in `Layout`

Inspired by the zulip conversation about how `Layout` should better enforce `size <= isize::MAX as usize`, this uses an N-variant enum on N-bit platforms to require at the validity level that the existing invariant of "must be a power of two" is upheld.

This was MIRI can catch it, and means there's a more-specific type for `Layout` to store than just `NonZeroUsize`.

It's left as `pub(crate)` here; a future PR could consider giving it a tracking issue for non-internal usage.
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 9, 2022
Rollup of 7 pull requests

Successful merges:

 - rust-lang#94794 (Clarify indexing into Strings)
 - rust-lang#95361 (Make non-power-of-two alignments a validity error in `Layout`)
 - rust-lang#95369 (Fix `x test src/librustdoc` with `download-rustc` enabled )
 - rust-lang#95805 (Left overs of rust-lang#95761)
 - rust-lang#95808 (expand: Remove `ParseSess::missing_fragment_specifiers`)
 - rust-lang#95817 (hide another #[allow] directive from a docs example)
 - rust-lang#95831 (Use bitwise XOR in to_ascii_uppercase)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit e4b4bf1 into rust-lang:master Apr 9, 2022
@rustbot rustbot added this to the 1.62.0 milestone Apr 9, 2022
@scottmcm scottmcm deleted the valid-align branch April 10, 2022 06:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants