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

Fix _mm_extract_ps example. #1261

Merged
merged 1 commit into from
Dec 4, 2021

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Nov 29, 2021

The example fails when run with rustdoc since this crate denies warnings. The test has an unneeded unsafe block which triggers unused_unsafe.

This normally doesn't show up in CI since it requires testing with a -C target-cpu that has sse4.1.

@rust-highfive
Copy link

r? @Amanieu

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

Comment on lines 156 to 163
/// # unsafe fn worker() {
/// let mut float_store = vec![1.0, 1.0, 2.0, 3.0];
/// unsafe {
/// let simd_floats = _mm_set_ps(2.5, 5.0, 7.5, 10.0);
/// let x: i32 = _mm_extract_ps::<2>(simd_floats);
/// float_store.push(f32::from_bits(x as u32));
/// }
/// assert_eq!(float_store, vec![1.0, 1.0, 2.0, 3.0, 5.0]);
/// # }
/// # unsafe { worker() }
Copy link
Member

Choose a reason for hiding this comment

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

This appears "unused" from inside the source, but not to the user reading the docs, due to the unsafe "worker" function (that is required to use target_feature(enable)) it is nested inside, so if a user copies this code from the rendered docs with this change, they will need to readd the unsafe { }. That is to say: this makes the documentation less correct. This is an instance of unused_unsafe only because fn worker is not annotated #[warn(unsafe_op_in_unsafe_fn)], which should also eliminate the warning, and without altering the correctness of the documentation.

Copy link
Contributor Author

@ehuss ehuss Nov 29, 2021

Choose a reason for hiding this comment

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

Yea, I understand why it was done. I was just changing it to match the style of all the other examples. I certainly could allow the warning, but then it would be inconsistent.

My impression is that anyone using low-level SIMD instructions knows that they will need to be unsafe. Also, if they are pasting the example into an unsafe function, they will end up with the same warning if they include an unsafe block.

EDIT: Though I am fine with allowing the warning if that's what is wanted.

@Amanieu
Copy link
Member

Amanieu commented Nov 30, 2021

CI is blocked on rust-lang/rust#91381.

@moxian
Copy link

moxian commented Dec 1, 2021

Pardon me bumming in like this, but should this PR even be needed in face of https://rust-lang.github.io/rfcs/2585-unsafe-block-in-unsafe-fn.html ? Wouldn't the better fix be adding #[warn(unsafe_op_in_unsafe_fn)] on the unsafe worker() instead (that changes from "unsafe blocks inside unsafe fn are redundant and are warned about" to "unsafe blocks inside unsafe fn are required, and their absence is warned about") ?

@Amanieu Amanieu merged commit 18cc733 into rust-lang:master Dec 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants