-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rename Unsafe to Safety #125077
Rename Unsafe to Safety #125077
Conversation
rustbot has assigned @petrochenkov. Use |
Some changes occurred in need_type_info.rs cc @lcnr Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in compiler/rustc_codegen_gcc Some changes occurred in src/librustdoc/clean/types.rs cc @camelid Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt Some changes occurred in src/tools/clippy cc @rust-lang/clippy This PR changes Stable MIR cc @oli-obk, @celinval, @ouz-a HIR ty lowering was modified cc @fmease changes to the core type system |
r? @cjgillot |
516dffb
to
6922a2c
Compare
This comment has been minimized.
This comment has been minimized.
I'm going to wait on a review and decision about this or #124455 or any other alternative before fixing CI and possible conflicts as it is a lot of work to keep all these in a mergeable state. |
☔ The latest upstream changes (presumably #125179) made this pull request unmergeable. Please resolve the merge conflicts. |
27f1aee
to
ffa3007
Compare
This comment has been minimized.
This comment has been minimized.
ffa3007
to
80a395e
Compare
rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead. cc @rust-lang/rust-analyzer |
0ecc00d
to
134936e
Compare
134936e
to
6b46a91
Compare
r? jackh726 @bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (eb1a5c9): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 3.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary 5.2%, secondary 6.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 669.868s -> 667.962s (-0.28%) |
…=jackh726 Rename Unsafe to Safety Alternative to rust-lang#124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks. This leaves us today with: ```rust enum ast::Safety { Unsafe(Span), Default, // Safe (going to be added for unsafe extern blocks) } enum hir::Safety { Unsafe, Safe, } ``` We would convert from `ast::Safety::Default` into the right Safety level according the context.
…-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.
…-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.
Rollup 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.
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding
ast::Safety::Safe
that's useful for unsafe extern blocks.This leaves us today with:
We would convert from
ast::Safety::Default
into the right Safety level according the context.