Properly gate safe keyword in pre-expansion
#126757
Conversation
rustbot
added
S-waiting-on-review
compiler-errors
added
beta-nominated
|
r=me with CI green |
|
Well ... maybe before merging this let me see if I can quickly fix the issue. We can have this to approve it and backport quickly but if I can do a right fix is going to be better as the backport can apply cleanly. |
|
What change do you have in mind, @spastorino? I'd kinda rather we backport something simple like this rather than a more invasive change, like splitting out My understanding is that after this PR lands, nothing needs to be futher backported since this is the only thing that has regressed for users not using stable features. |
|
Specifically, how is this fix not sufficient? Usage of a new unstable keyword should be gated in the parser regardless of if we need to do further validation later on in |
|
Michael this #126758 is the fix I was talking about. Yes, you're right that safe should be gated, so we should probably also apply your patch but remember that unsafe extern blocks just need a stabilization report and the feature flag is going away. As soon as the feature flag goes away, this fix is also going to be lost. |
|
I meant, it's true though that in terms of backport we can apply yours but if we don't apply #126758 we risk reintroducing the regression (that's what I meant) |
I think the regression you mean is #126749, which is a separate issue from #126755. The fact that we don't validate where a I still think we should land this ASAP. After that, I don't see why we need to beta backport #126758 since after this PR it only affects nightly code. |
|
Agreed on everything you've said. The relationship I was talking about was exactly what you said, the important bug to address quickly is the regression on stable and your PR addressed this while we have the feature flag, my PR addresses it when the thing is stabilized. Agreed that we should apply both PRs and backport yours. @bors r+ rollup |
bors
added
S-waiting-on-bors
Properly gate `safe` keyword in pre-expansion This PR gates `safe` keyword in pre-expansion contexts. Should mitigate the fallout of rust-lang#126755, which is that `safe` is now usable on beta lol. r? `@spastorino` or `@oli-obk` cc rust-lang#124482 tracking rust-lang#123743
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#125627 (migration lint for `expr2024` for the edition 2024) - rust-lang#126481 (Add `powerpc-unknown-openbsd` maintaince status) - rust-lang#126613 (Print the tested value in int_log tests) - rust-lang#126617 (Expand `avx512_target_feature` to include VEX variants) - rust-lang#126686 (Add `#[rustc_dump_{predicates,item_bounds}]`) - rust-lang#126700 (Make edition dependent `:expr` macro fragment act like the edition-dependent `:pat` fragment does) - rust-lang#126707 (Pass target to inaccessible-temp-dir rmake test) - rust-lang#126757 (Properly gate `safe` keyword in pre-expansion) r? `@ghost` `@rustbot` modify labels: rollup
Properly gate `safe` keyword in pre-expansion This PR gates `safe` keyword in pre-expansion contexts. Should mitigate the fallout of rust-lang#126755, which is that `safe` is now usable on beta lol. r? ``@spastorino`` or ``@oli-obk`` cc rust-lang#124482 tracking rust-lang#123743
…kingjubilee Rollup of 9 pull requests Successful merges: - rust-lang#124101 (Add PidFd::{kill, wait, try_wait}) - rust-lang#126125 (Improve conflict marker recovery) - rust-lang#126481 (Add `powerpc-unknown-openbsd` maintaince status) - rust-lang#126613 (Print the tested value in int_log tests) - rust-lang#126617 (Expand `avx512_target_feature` to include VEX variants) - rust-lang#126707 (Pass target to inaccessible-temp-dir rmake test) - rust-lang#126712 (Migrate `relocation-model`, `error-writing-dependencies` and `crate-name-priority` `run-make` tests to rmake) - rust-lang#126757 (Properly gate `safe` keyword in pre-expansion) - rust-lang#126758 (Do not allow safe/unsafe on static and fn items) r? `@ghost` `@rustbot` modify labels: rollup
|
@bors p=1 rollup=never |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (4e6de37): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)Results (secondary 3.5%)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 (secondary 0.8%)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: 695.451s -> 698.008s (0.37%) |
Mark-Simulacrum
added
the
perf-regression-triaged
|
Looks like a minimal regression (maybe spurious/bimodality) and the change is clearly needed. Marking as triaged. |
rustbot
added
the
beta-accepted
cuviper
removed
the
beta-nominated
[beta] backports - Properly gate `safe` keyword in pre-expansion rust-lang#126757 - Switch back `non_local_definitions` lint to allow-by-default rust-lang#127015 - Stall computing instance for drop shim until it has no unsubstituted const params rust-lang#127068 - Update LLVM submodule rust-lang#127190 r? cuviper
[beta] backports - Properly gate `safe` keyword in pre-expansion rust-lang#126757 - Switch back `non_local_definitions` lint to allow-by-default rust-lang#127015 - Stall computing instance for drop shim until it has no unsubstituted const params rust-lang#127068 - Update LLVM submodule rust-lang#127190 - Change to the NetBSD archive URL rather than the CDN rust-lang#127232 r? cuviper
[beta] backports - Properly gate `safe` keyword in pre-expansion rust-lang#126757 - Switch back `non_local_definitions` lint to allow-by-default rust-lang#127015 - Stall computing instance for drop shim until it has no unsubstituted const params rust-lang#127068 - Update LLVM submodule rust-lang#127190 - Change to the NetBSD archive URL rather than the CDN rust-lang#127232 r? cuviper
[beta] backports - Properly gate `safe` keyword in pre-expansion rust-lang#126757 - Switch back `non_local_definitions` lint to allow-by-default rust-lang#127015 - Stall computing instance for drop shim until it has no unsubstituted const params rust-lang#127068 - Update LLVM submodule rust-lang#127190 - Change to the NetBSD archive URL rather than the CDN rust-lang#127232 r? cuviper
…-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.
This PR gates
safekeyword in pre-expansion contexts. Should mitigate the fallout of #126755, which is thatsafeis now usable on beta lol.r? @spastorino or @oli-obk
cc #124482 tracking #123743