Repository navigation
Tracking Issue for RFC 3325: unsafe attributes #123757
Description
This is a tracking issue for RFC 3325: unsafe attributes
RFC: rust-lang/rfcs#3325
Issues:
F-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.
- Implement in nightly Rust 2024.
- Implement migration lints.
- rustfmt support
- N/A: Add documentation to the dev guide.
- See the instructions.
- Add documentation to the reference.
- Add documentation to the edition guide.
- N/A: Add formatting for new syntax to the style guide.
- See the nightly style procedure.
- Stabilize in all editions.
- Ensure ready for Rust 2024 stabilization.
Unresolved Questions
- Different lint staging. The lint on using existing unsafe attributes like
no_mangleoutsideunsafe(...)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.
Activity
traviscross commentedon Apr 21, 2024
@rustbot assign @carbotaniuman
@carbotaniuman has volunteered to own this item to get it over the line for the edition. Huge thanks for that.
Auto merge of rust-lang#124214 - carbotaniuman:parse_unsafe_attrs, r=…
traviscross commentedon May 14, 2024
@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 commentedon Jun 5, 2024
@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.
Rollup merge of rust-lang#124214 - carbotaniuman:parse_unsafe_attrs, …
20 remaining items
traviscross commentedon Aug 20, 2024
@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 commentedon Aug 28, 2024
Let's reopen this to track documentation: somewhere around here, it should document what the safety requirements are for these attributes:
ehuss commentedon Aug 28, 2024
@RalfJung That documentation has already been updated by rust-lang/reference#1539. Can you say if that covers what you are expecting?
geofft commentedon Aug 28, 2024
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 commentedon Aug 29, 2024
Ah, fair, yes that should suffice for now. :)
arthuro555 commentedon Sep 9, 2024
RalfJung commentedon Sep 9, 2024
Auto merge of rust-lang#128771 - carbotaniuman:stabilize_unsafe_attr,…
RalfJung commentedon Oct 16, 2024
Turns out there's some follow-up cleanup we can do, now that we have a proper notion of "unsafe attributes": #131801
Turn on rust-2024-compatibility lints in a test
Turn on rust-2024-compatibility lints in test crate