Tracking Issue for RFC 3325: unsafe attributes #123757

traviscross · 2024-04-10T21:33:15Z

This is a tracking issue for RFC 3325: unsafe attributes

RFC: rust-lang/rfcs#3325
Issues: F-unsafe_attributes `#![feature(unsafe_attributes)]`

The feature gate for the issue is #![feature(unsafe_attributes)].

For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see this comment here

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Accept the RFC.
- unsafe attributes rfcs#3325
Implement in nightly Rust 2024.
Implement migration lints.
- Add hard error and migration lint for unsafe attrs #126177
rustfmt support
N/A: Add documentation to the dev guide.
- See the instructions.
Add documentation to the reference.
- Add some basic docs for unsafe attrs reference#1539
- 2024: Add unsafe attribute differences reference#1579
Add documentation to the edition guide.
- Add 2024 unsafe attributes. edition-guide#308
N/A: Add formatting for new syntax to the style guide.
- See the nightly style procedure.
Stabilize in all editions.
- Stabilize unsafe_attributes #128771
Ensure ready for Rust 2024 stabilization.

Unresolved Questions

Different lint staging. The lint on using existing unsafe attributes like no_mangle outside unsafe(...) could be staged in various ways: it could be warn-by-default to start or we wait a while before to do that, it could be edition-dependent, it might eventually be deny-by-default or even a hard error on some editions -- there are lots of details here, which can be determined later during the process.

Implementation history

cc @RalfJung @carbotaniuman @rust-lang/style

This issue has been assigned to @carbotaniuman via this comment.

The text was updated successfully, but these errors were encountered:

traviscross · 2024-04-21T23:12:12Z

@rustbot assign @carbotaniuman

@carbotaniuman has volunteered to own this item to get it over the line for the edition. Huge thanks for that.

…<try> Parse unsafe attributes Initial parse implementation for rust-lang#123757 This is the initial work to parse unsafe attributes, which is represented as an extra `unsafety` field in `MetaItem` and `AttrItem`. There's two areas in the code where it appears that parsing is done manually and not using the parser stuff, and I'm not sure how I'm supposed to thread the change there.

traviscross · 2024-05-14T20:14:40Z

@rustbot labels +I-style-nominated

There's probably not a lot for T-style to do here, but strictly speaking, this is a kind of new syntax, so it may be worth at least a short discussion for visibility.

traviscross · 2024-06-05T20:02:05Z

@rustbot labels -I-style-nominated

We discussed this in the style team meeting today and confirmed that this will not require any special handling or changes to the style guide.

…r=michaelwoerister Parse unsafe attributes Initial parse implementation for rust-lang#123757 This is the initial work to parse unsafe attributes, which is represented as an extra `unsafety` field in `MetaItem` and `AttrItem`. There's two areas in the code where it appears that parsing is done manually and not using the parser stuff, and I'm not sure how I'm supposed to thread the change there.

Rollup merge of rust-lang#124214 - carbotaniuman:parse_unsafe_attrs, r=michaelwoerister Parse unsafe attributes Initial parse implementation for rust-lang#123757 This is the initial work to parse unsafe attributes, which is represented as an extra `unsafety` field in `MetaItem` and `AttrItem`. There's two areas in the code where it appears that parsing is done manually and not using the parser stuff, and I'm not sure how I'm supposed to thread the change there.

ehuss · 2024-06-20T18:27:26Z

Edition docs are up at rust-lang/edition-guide#308.

…r=jieyouxu Add hard error and migration lint for unsafe attrs More implementation work for rust-lang#123757 This adds the migration lint for unsafe attributes, as well as making it a hard error in Rust 2024.

Rollup merge of rust-lang#126177 - carbotaniuman:unsafe_attr_errors, r=jieyouxu Add hard error and migration lint for unsafe attrs More implementation work for rust-lang#123757 This adds the migration lint for unsafe attributes, as well as making it a hard error in Rust 2024.

…ification, r=estebank,traviscross More unsafe attr verification This code denies unsafe on attributes such as `#[test]` and `#[ignore]`, while also changing the `MetaItem` parsing so `unsafe` in args like `#[allow(unsafe(dead_code))]` is not accidentally allowed. Tracking: - rust-lang#123757

…ication, r=estebank,traviscross More unsafe attr verification This code denies unsafe on attributes such as `#[test]` and `#[ignore]`, while also changing the `MetaItem` parsing so `unsafe` in args like `#[allow(unsafe(dead_code))]` is not accidentally allowed. Tracking: - rust-lang#123757

…r=estebank,traviscross More unsafe attr verification This code denies unsafe on attributes such as `#[test]` and `#[ignore]`, while also changing the `MetaItem` parsing so `unsafe` in args like `#[allow(unsafe(dead_code))]` is not accidentally allowed. Tracking: - rust-lang/rust#123757

…r, r=nnethercote Stabilize `unsafe_attributes` # Stabilization report ## Summary This is a tracking issue for the RFC 3325: unsafe attributes We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`. RFC: rust-lang/rfcs#3325 Tracking issue: rust-lang#123757 ## What is stabilized ### Summary of stabilization Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones. ```rust #[unsafe(no_mangle)] fn a() {} #[cfg_attr(any(), unsafe(export_name = "c"))] fn b() {} ``` For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](rust-lang#124214 (comment)) ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.

… r=nnethercote Stabilize `unsafe_attributes` # Stabilization report ## Summary This is a tracking issue for the RFC 3325: unsafe attributes We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`. RFC: rust-lang/rfcs#3325 Tracking issue: rust-lang#123757 ## What is stabilized ### Summary of stabilization Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones. ```rust #[unsafe(no_mangle)] fn a() {} #[cfg_attr(any(), unsafe(export_name = "c"))] fn b() {} ``` For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](rust-lang#124214 (comment)) ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.

traviscross · 2024-08-20T19:56:58Z

@rustbot labels +S-tracking-ready-for-edition

We reviewed this in the edition call today. This item is ready for Rust 2024.

Thanks to @carbotaniuman for pushing forward this item. Thanks to @RalfJung for writing up the RFC. And thanks to the many reviewers.

RalfJung · 2024-08-28T18:31:26Z

Let's reopen this to track documentation: somewhere around here, it should document what the safety requirements are for these attributes:

no_mangle
link_section
export_name

ehuss · 2024-08-28T18:47:39Z

@RalfJung That documentation has already been updated by rust-lang/reference#1539. Can you say if that covers what you are expecting?

geofft · 2024-08-28T19:24:06Z

I think we could add a sentence like "It may also lead to addresses being accessed with the wrong address space, for instance, on Harvard architectures" to address #76507 specifically, but I think "place data and code into sections
of memory not expecting them" sort of covers that already.

RalfJung · 2024-08-29T05:55:54Z

Ah, fair, yes that should suffice for now. :)

… r=nnethercote Stabilize `unsafe_attributes` # Stabilization report ## Summary This is a tracking issue for the RFC 3325: unsafe attributes We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`. RFC: rust-lang/rfcs#3325 Tracking issue: rust-lang#123757 ## What is stabilized ### Summary of stabilization Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones. ```rust #[unsafe(no_mangle)] fn a() {} #[cfg_attr(any(), unsafe(export_name = "c"))] fn b() {} ``` For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](rust-lang#124214 (comment)) ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.

RalfJung · 2024-10-16T19:59:54Z

Turns out there's some follow-up cleanup we can do, now that we have a proper notion of "unsafe attributes": #131801

carbotaniuman mentioned this issue Apr 21, 2024

Parse unsafe attributes #124214

Merged

rustbot self-assigned this Apr 21, 2024

traviscross mentioned this issue May 6, 2024

unsafe attributes rust-lang/rfcs#3325

Merged

rustbot added the I-style-nominated Nominated for discussion during a style team meeting. label May 14, 2024

traviscross added S-tracking-impl-incomplete Status: The implementation is incomplete. S-tracking-needs-migration-lint Status: This item needs a migration lint. S-tracking-needs-documentation Status: Needs documentation. labels May 21, 2024

rustbot removed the I-style-nominated Nominated for discussion during a style team meeting. label Jun 5, 2024

carbotaniuman mentioned this issue Jun 8, 2024

Add hard error and migration lint for unsafe attrs #126177

Merged

traviscross removed the S-tracking-needs-migration-lint Status: This item needs a migration lint. label Jun 8, 2024

jieyouxu added L-unsafe_attr_outside_unsafe Lint: unsafe_attr_outside_unsafe F-unsafe_attributes `#![feature(unsafe_attributes)]` labels Jun 9, 2024

traviscross added S-tracking-ready-to-stabilize Status: This is ready to stabilize; it may need a stabilization report and a PR and removed S-tracking-impl-incomplete Status: The implementation is incomplete. labels Jun 25, 2024

traviscross mentioned this issue Jul 10, 2024

More unsafe attr verification #127543

Merged

carbotaniuman mentioned this issue Jul 21, 2024

Add some basic docs for unsafe attrs rust-lang/reference#1539

Merged

dtolnay mentioned this issue Jul 21, 2024

Parse unsafe attributes dtolnay/syn#1710

Closed

traviscross removed the S-tracking-needs-documentation Status: Needs documentation. label Jul 22, 2024

carbotaniuman mentioned this issue Aug 7, 2024

Stabilize unsafe_attributes #128771

Merged

traviscross added S-tracking-ready-for-edition Status: This issue is ready for inclusion in the edition. and removed S-tracking-ready-to-stabilize Status: This is ready to stabilize; it may need a stabilization report and a PR labels Aug 20, 2024

traviscross closed this as completed Aug 20, 2024

RalfJung mentioned this issue Aug 28, 2024

#[no_mangle] is unsafe in the presence of name collisions #28179

Closed

geofft mentioned this issue Aug 28, 2024

#[link_section] is unsound on Harvard architectures #76507

Closed

RalfJung reopened this Aug 28, 2024

RalfJung closed this as completed Aug 29, 2024

This comment was marked as off-topic.

Sign in to view

This comment was marked as resolved.

Sign in to view

traviscross mentioned this issue Sep 17, 2024

Rust 2024 Edition rust-lang/rust-project-goals#117

Open

RalfJung mentioned this issue Oct 16, 2024

We have two independent checks for "is this attribute unsafe" #131801

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for RFC 3325: unsafe attributes #123757

Tracking Issue for RFC 3325: unsafe attributes #123757

traviscross commented Apr 10, 2024 •

edited

Loading

traviscross commented Apr 21, 2024

traviscross commented May 14, 2024

traviscross commented Jun 5, 2024

ehuss commented Jun 20, 2024

traviscross commented Aug 20, 2024 •

edited

Loading

RalfJung commented Aug 28, 2024 •

edited

Loading

ehuss commented Aug 28, 2024

geofft commented Aug 28, 2024

RalfJung commented Aug 29, 2024

This comment was marked as off-topic.

This comment was marked as resolved.

RalfJung commented Oct 16, 2024

Tracking Issue for RFC 3325: unsafe attributes #123757

Tracking Issue for RFC 3325: unsafe attributes #123757

Comments

traviscross commented Apr 10, 2024 • edited Loading

About tracking issues

Steps

Unresolved Questions

Implementation history

traviscross commented Apr 21, 2024

traviscross commented May 14, 2024

traviscross commented Jun 5, 2024

ehuss commented Jun 20, 2024

traviscross commented Aug 20, 2024 • edited Loading

RalfJung commented Aug 28, 2024 • edited Loading

ehuss commented Aug 28, 2024

geofft commented Aug 28, 2024

RalfJung commented Aug 29, 2024

This comment was marked as off-topic.

This comment was marked as resolved.

RalfJung commented Oct 16, 2024

traviscross commented Apr 10, 2024 •

edited

Loading

traviscross commented Aug 20, 2024 •

edited

Loading

RalfJung commented Aug 28, 2024 •

edited

Loading