format safety keywords on static items by ytmimi · Pull Request #6204 · rust-lang/rustfmt (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation7 Commits1 Checks26 Files changed

Conversation

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

[ Show hidden characters]({{ revealButtonHref }})

ytmimi

This includes both ast::StaticItem and ast::StaticForeignItem. safety was added to both ast::StaticItem and ast::SaticForeignItem in rust-lang/rust#124482.

@ytmimi

This includes both ast::StaticItem and ast::StaticForeignItem. safety was added to both ast::StaticItem and ast::SaticForeignItem in rust-lang/rust#124482.

ytmimi
#![feature(unsafe_extern_blocks)]
safe static TEST1: i32;

Choose a reason for hiding this comment

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

I'm not sure that formatting the safety here is necessary per this comment https://github.com/rust-lang/rust/pull/124482/files#r1608953719. For now it parses, so I don't think there's an issue, though I'm happy to revert the changes to StaticParts if we don't think this is necessary.

Choose a reason for hiding this comment

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

Let's keep it, since it doesn't hurt.

compiler-errors
#![feature(unsafe_extern_blocks)]
safe static TEST1: i32;

Choose a reason for hiding this comment

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

Let's keep it, since it doesn't hurt.

calebcartwright

@calebcartwright

probably warrants an addition in the release notes too

@ytmimi

@calebcartwright I'll update the CHANGELOG PR #6004 in just a bit to include this

Edit: The CHANGELOG PR was updated!

@ytmimi ytmimi deleted the dont_drop_static_safety branch

June 21, 2024 14:16

workingjubilee

@@ -1989,11 +1994,13 @@ fn rewrite_static(
static_parts: &StaticParts<'_>,
offset: Indent,
) -> Option {
println!("rewriting static");

Choose a reason for hiding this comment

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

You left in a debug print, it seems.

Choose a reason for hiding this comment

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

I am surprised that this did not make any of the tests fail...?

Choose a reason for hiding this comment

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

I am surprised that this did not make any of the tests fail...?

same (#6210 (comment))

we'll do a postmortem of sorts to review and hopefully identify some preventative measures to prevent a recurrence

tgross35 added a commit to tgross35/rust that referenced this pull request

Aug 3, 2024

@tgross35

…-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. 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.

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

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

@matthiaskrgr

…-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. 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.

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

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, 2024

@rust-timer

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. 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.

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

Unresolved questions

I am not aware of any unresolved questions.