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.

Sign up for GitHub

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

Jump to bottom

safe keyword is not feature-gated #126755

Closed
compiler-errors opened this issue Jun 20, 2024 · 4 comments
Closed

safe keyword is not feature-gated #126755

compiler-errors opened this issue Jun 20, 2024 · 4 comments
Assignees
@compiler-errors
Labels
P-high High priority regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@compiler-errors
Copy link
Member

compiler-errors commented Jun 20, 2024 •
edited by traviscross
Loading

In #126749, @ehuss reports:

Another issue appears that safe is not feature-gated. The following seems to build without a feature gate:

safe fn foo() {}

Originally posted by @ehuss in #126749 (comment)

Tracking:
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jun 20, 2024
@compiler-errors compiler-errors added regression-from-stable-to-beta Performance or correctness regression from stable to beta. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Jun 20, 2024
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Jun 20, 2024
@compiler-errors compiler-errors self-assigned this Jun 20, 2024
@compiler-errors
Copy link
Member Author

this regressed in #124482

@compiler-errors compiler-errors mentioned this issue Jun 20, 2024
Merged
@traviscross
Copy link
Contributor

cc @spastorino

@traviscross traviscross mentioned this issue Jun 20, 2024
Closed
10 tasks
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 20, 2024
@matthiaskrgr
Rollup merge of rust-lang#126757 - compiler-errors:safe, r=spastorino
3319aae 
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
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Jun 21, 2024
@workingjubilee
Rollup merge of rust-lang#126757 - compiler-errors:safe, r=spastorino
78d6afa 
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
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 21, 2024
@bors
Auto merge of rust-lang#126757 - compiler-errors:safe, r=spastorino
4e6de37 
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
@apiraino
Copy link
Contributor

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Jun 21, 2024
@wesleywiser wesleywiser added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 21, 2024
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Jun 28, 2024
@bors
Auto merge of #126757 - compiler-errors:safe, r=spastorino
0c3643b 
Properly gate `safe` keyword in pre-expansion

This PR gates `safe` keyword in pre-expansion contexts. Should mitigate the fallout of rust-lang/rust#126755, which is that `safe` is now usable on beta lol.

r? `@spastorino` or `@oli-obk`

cc #124482 tracking #123743
@compiler-errors
Copy link
Member Author

This got fixed and beta backported

@spastorino spastorino mentioned this issue Jul 18, 2024
Merged
tgross35 added a commit to tgross35/rust that referenced this issue Aug 3, 2024
@tgross35
Rollup merge of rust-lang#127921 - spastorino:stabilize-unsafe-extern…
16e6cd2 
…-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 issue Aug 3, 2024
@matthiaskrgr
Rollup merge of rust-lang#127921 - spastorino:stabilize-unsafe-extern…
7d9ed2a 
…-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 issue Aug 3, 2024
@rust-timer
Unrolled build for rust-lang#127921
6841bd3 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@compiler-errors compiler-errors

Labels
P-high High priority regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@wesleywiser @traviscross @compiler-errors @apiraino @rustbot