Fire unsafe_code lint on unsafe extern blocks by spastorino · Pull Request #127535 · rust-lang/rust
rustbot
added
S-waiting-on-review
labels
Jul 9, 2024
bors
added
S-waiting-on-bors
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.labels
Jul 12, 2024matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Jul 12, 2024…rn_blocks, r=oli-obk Fire unsafe_code lint on unsafe extern blocks Fixes rust-lang#126738
bors added a commit to rust-lang-ci/rust that referenced this pull request
Jul 12, 2024…kingjubilee Rollup of 11 pull requests Successful merges: - rust-lang#126502 (Ignore allocation bytes in some mir-opt tests) - rust-lang#126922 (add lint for inline asm labels that look like binary) - rust-lang#127209 (Added the `xop` target-feature and the `xop_target_feature` feature gate) - rust-lang#127310 (Fix import suggestion ice) - rust-lang#127338 (Migrate `extra-filename-with-temp-outputs` and `issue-85019-moved-src-dir` `run-make` tests to rmake) - rust-lang#127381 (Migrate `issue-83045`, `rustc-macro-dep-files` and `env-dep-info` `run-make` tests to rmake) - rust-lang#127535 (Fire unsafe_code lint on unsafe extern blocks) - rust-lang#127619 (Suggest using precise capturing for hidden type that captures region) - rust-lang#127631 (Remove `fully_normalize`) - rust-lang#127632 (Implement `precise_capturing` support for rustdoc) - rust-lang#127660 (Rename the internal `const_strlen` to just `strlen`) r? `@ghost` `@rustbot` modify labels: rollup
tgross35 added a commit to tgross35/rust that referenced this pull request
Aug 3, 2024…-blocks, r=compiler-errors Stabilize unsafe extern blocks (RFC 3484) # Stabilization report ## Summary This is a tracking issue for the RFC 3484: Unsafe Extern Blocks We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](rust-lang/rfcs#3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use. RFC: rust-lang/rfcs#3484 Tracking issue: rust-lang#123743 ## What is stabilized ### Summary of stabilization We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results. ```rust unsafe extern { // sqrt (from libm) may be called with any `f64` pub safe fn sqrt(x: f64) -> f64; // strlen (from libc) requires a valid pointer, // so we mark it as being an unsafe fn pub unsafe fn strlen(p: *const c_char) -> usize; // this function doesn't say safe or unsafe, so it defaults to unsafe pub fn free(p: *mut core::ffi::c_void); pub safe static IMPORTANT_BYTES: [u8; 256]; pub safe static LINES: SyncUnsafeCell<i32>; } ``` ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`. ## History - rust-lang#124482 - rust-lang#124455 - rust-lang#125077 - rust-lang#125522 - rust-lang#126738 - rust-lang#126749 - rust-lang#126755 - rust-lang#126757 - rust-lang#126758 - rust-lang#126756 - rust-lang#126973 - rust-lang#127535 - rust-lang/rustfmt#6204 ## Unresolved questions I am not aware of any unresolved questions.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Aug 3, 2024…-blocks, r=compiler-errors Stabilize unsafe extern blocks (RFC 3484) # Stabilization report ## Summary This is a tracking issue for the RFC 3484: Unsafe Extern Blocks We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](rust-lang/rfcs#3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use. RFC: rust-lang/rfcs#3484 Tracking issue: rust-lang#123743 ## What is stabilized ### Summary of stabilization We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results. ```rust unsafe extern { // sqrt (from libm) may be called with any `f64` pub safe fn sqrt(x: f64) -> f64; // strlen (from libc) requires a valid pointer, // so we mark it as being an unsafe fn pub unsafe fn strlen(p: *const c_char) -> usize; // this function doesn't say safe or unsafe, so it defaults to unsafe pub fn free(p: *mut core::ffi::c_void); pub safe static IMPORTANT_BYTES: [u8; 256]; pub safe static LINES: SyncUnsafeCell<i32>; } ``` ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`. ## History - rust-lang#124482 - rust-lang#124455 - rust-lang#125077 - rust-lang#125522 - rust-lang#126738 - rust-lang#126749 - rust-lang#126755 - rust-lang#126757 - rust-lang#126758 - rust-lang#126756 - rust-lang#126973 - rust-lang#127535 - rust-lang/rustfmt#6204 ## Unresolved questions I am not aware of any unresolved questions.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Aug 3, 2024Rollup merge of rust-lang#127921 - spastorino:stabilize-unsafe-extern-blocks, r=compiler-errors Stabilize unsafe extern blocks (RFC 3484) # Stabilization report ## Summary This is a tracking issue for the RFC 3484: Unsafe Extern Blocks We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](rust-lang/rfcs#3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use. RFC: rust-lang/rfcs#3484 Tracking issue: rust-lang#123743 ## What is stabilized ### Summary of stabilization We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results. ```rust unsafe extern { // sqrt (from libm) may be called with any `f64` pub safe fn sqrt(x: f64) -> f64; // strlen (from libc) requires a valid pointer, // so we mark it as being an unsafe fn pub unsafe fn strlen(p: *const c_char) -> usize; // this function doesn't say safe or unsafe, so it defaults to unsafe pub fn free(p: *mut core::ffi::c_void); pub safe static IMPORTANT_BYTES: [u8; 256]; pub safe static LINES: SyncUnsafeCell<i32>; } ``` ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`. ## History - rust-lang#124482 - rust-lang#124455 - rust-lang#125077 - rust-lang#125522 - rust-lang#126738 - rust-lang#126749 - rust-lang#126755 - rust-lang#126757 - rust-lang#126758 - rust-lang#126756 - rust-lang#126973 - rust-lang#127535 - rust-lang/rustfmt#6204 ## Unresolved questions I am not aware of any unresolved questions.
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