Tracking Issue for RFC #2972: Constrained Naked Functions #90957

nikomatsakis · 2021-11-16T19:28:01Z

This is a tracking issue for the RFC "Constrained Naked Functions" (rust-lang/rfcs#2972).
The feature gate for the issue is #![feature(naked_functions)].

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

Implement the RFC
Confirm that all errors and warnings are emitted properly
Final review of attributes that are incompatible with #[naked]
Determine precise inlining gurantees
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

None.

Implementation history

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

safinaskar · 2022-01-23T08:53:53Z

"produce a clear warning if any of the above suggestions are not heeded" in RFC seems to contain typo

bstrie · 2022-01-25T21:50:28Z

This is implemented, checking the box.

Adding a new step: "Confirm that all errors and warnings are emitted properly".

bstrie · 2022-02-02T19:45:53Z

Request for Stabilization

A proposal that the naked_functions feature be stabilized for Rust 1.60, to be released 2022-04-07. A stabilization PR can be found at #93587.

Summary

Adds a new attribute, #[naked], which may be applied to functions. When applied to a function, the compiler will not emit a function prologue when generating code for this function. This attribute is analogous to __attribute__((naked)) in C. The use of this feature allows the programmer to have precise control over the assembly that is generated for a given function.

The body of a naked function must consist of a single asm! invocation. This asm! invocation is heavily restricted: the only legal operands are const and sym, and the only legal options are noreturn (which is mandatory) and att_syntax. In lieu of specifying operands, the asm! within a naked function relies on the specified extern calling convention in order to determine the validity of registers.

An example of a naked function:

const THREE: usize = 3;

#[naked]
/// Adds three to a number and returns the result.
pub extern "sysv64" fn add_n(number: usize) -> usize {
    // SAFETY: the validity of these registers is guaranteed according to the "sysv64" ABI
    unsafe {
        std::arch::asm!(
            "add rdi, {}",
            "mov rax, rdi",
            "ret",
            const THREE,
            options(noreturn)
        );
    }
}

Documentation

The Rust Reference: rust-lang/reference#1153

Tests

codegen/naked-functions.rs: tests for the absence of a function prologue.
codegen/naked-noinline.rs: tests for the presence of naked and noinline LLVM attributes.
ui/asm/naked-functions.rs: tests that naked functions cannot accept patterns as function parameters, that referencing their function parameters is prohibited, that their body must consist of a single asm! block, that they must specify the noreturn option, that they must not specify any other option except att_syntax, that they only support const and sym operands, that they warn when used with extern "Rust", and that they are incompatible with the inline attribute.
ui/asm/naked-functions-ffi.rs: tests that a warning occurs when the function signature contains types that are not FFI-safe.
ui/asm/naked-functions-unused.rs: tests that the unused_variables lint is suppressed within naked functions.
ui/asm/naked-invalid-attr.rs: tests that the naked attribute is only valid on function definitions.

History

This feature was originally proposed in RFC 1201, filed on 2015-07-10 and accepted on 2016-03-21. Support for this feature was added in #32410, landing on 2016-03-23. Development languished for several years as it was realized that the semantics given in RFC 1201 were insufficiently specific. To address this, a minimal subset of naked functions was specified by RFC 2972, filed on 2020-08-07 and accepted on 2021-11-16. Prior to the acceptance of RFC 2972, all of the stricter behavior specified by RFC 2972 was implemented as a series of warn-by-default lints that would trigger on existing uses of the naked attribute; these lints became hard errors in #93153 on 2022-01-22. As a result, today RFC 2972 has completely superseded RFC 1201 in describing the semantics of the naked attribute.

Unresolved Questions

In C, __attribute__((naked)) prevents the compiler from generating both a function prologue and a function epilogue. However in Rust it was discovered that under some circumstances LLVM will choose to emit instructions following the body of a naked function, which is seemingly non-trivial to prevent. Since most of the utility of naked functions comes from preventing the prologue rather than the epilogue, for the time being this feature has restricted itself to only guaranteeing the absence of the prologue. Instead, the reference will specify that users must not rely on the presence of code following the body of a naked function, and that a future version of Rust reserves the right to guarantee the absence of such code.
Prior to stabilization, concerns were raised that the current implementation might not be capable of guaranteeing that a naked function is never inlined in every circumstance. Obviously the correctness of naked functions relies on Rust setting up the callstack as if a function call were being performed, even in cases where the function is ultimately inlined. However, there may be observable differences in behavior based on whether or not a naked function is inlined, e.g. due to exported symbols or named labels. Thus the reference will specify that implementations are not currently required to prevent the inlining of naked functions, but that a future version of Rust reserves the right to guarantee that naked functions are not inlined, and that users must not rely on any observable differences that may arise due to the inlining of a naked function.

This stabilizes the feature described in RFC 2972, which supersedes the earlier RFC 1201. Closes rust-lang#32408 Closes rust-lang#90957

bjorn3 · 2022-02-02T20:17:58Z

Since most of the utility of naked functions comes from preventing the prologue rather than the epilogue, for the time being this feature has restricted itself to only guaranteeing the absence of the prologue.

There is no observable difference between LLVM adding an epilogue and a following unnamed function starting with instructions identical to a regular epilogue.

bstrie · 2022-02-02T20:36:14Z

@bjorn3 I believe it can cause problems in circumstances such as #32408 (comment) . If someone were to work around that issue by assuming the existence of extra instructions and manually accounting for it, then their code would be broken if Rust ever stopped generating those instructions. It is this sort of edge case that this defensive wording is designed to address.

roblabla · 2022-02-02T20:45:26Z

Since most of the utility of naked functions comes from preventing the prologue rather than the epilogue, for the time being this feature has restricted itself to only guaranteeing the absence of the prologue.

There is no observable difference between LLVM adding an epilogue and a following unnamed function starting with instructions identical to a regular epilogue.

I believe it's possible to observe a difference when naked is coupled with #[link_section]. You could apply that attributed to a naked function to put it in a well-known section that you expect to only contain your function.

joshtriplett · 2022-02-02T20:52:54Z

👍 for stabilizing, though I'd like to make sure that there's consensus on #32408 (comment) .

joshtriplett · 2022-02-02T20:55:27Z

Shall we stabilize constrained naked functions?

@rfcbot merge

rfcbot · 2022-02-02T20:55:28Z

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

Amanieu · 2022-02-02T20:58:00Z

I'd like to have a whitelist of attributes that are allowed to be applies to a naked function. In the future we may want to lower naked functions directly to LLVM module-level assembly instead of using LLVM's native naked function support. For that to happen rustc needs to be able to manually translate any attributes (e.g. #[link_section]) to the corresponding asm directive.

comex · 2022-02-03T08:37:23Z

In the future we may want to lower naked functions directly to LLVM module-level assembly instead of using LLVM's native naked function support.

Why, because of the epilogue issue? Personally I would much rather see that fixed on LLVM’s end, rather than going to great lengths to work around it in rustc. Or is there another reason?

bjorn3 · 2022-02-03T08:40:59Z

Lowering to global_asm! would allow all codegen backends to share the same naked function handling. Also codegen backends without native inline assembly support (like cg_clif) will have to lower to global_asm! even if no code is shared between codegen backends, so it will need this same restriction.

bstrie · 2022-02-03T14:12:45Z

@comex In addition to the epilogue issue, it seems the inlining issue could also be resolved by lowering to global_asm!.

@Amanieu I'd be interested in seeing such a list. Obviously part of the appeal of naked functions is that they can be treated just like a normal function in most cases, which includes the ability to be marked with attributes (e.g. #[doc]), so I'm curious how restrictive this list would be. It occurs to me that, in addition to forbidding #[inline], naked functions also already forbid #[track_caller]; I should probably mention this in the reference.

roblabla · 2022-02-03T14:22:39Z

Most attributes that work with arbitrary functions should work with naked functions IMO. Taking the list here, those make sense to use with naked fns:

Conditional compilation: cfg, cfg_attr
Diagnostics: allow and company, deprecated
ABI...: link_section, export_name, no_mangle, used
Documentation: doc

The only ones that I think make sense to disallow are those in the "Code Generation" category: inline, cold, track_caller.

target_feature is an interesting one. I'm not sure what it does, it may make sense to allow it in naked fns.

…isibility, r=bjorn3 add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? ``@bjorn3``

…isibility, r=bjorn3 add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? `@bjorn3`

…isibility, r=bjorn3 add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? ``@bjorn3``

…ibility, r=<try> add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? `@bjorn3` try-job: x86_64-msvc try-job: i686-msvc

…ibility, r=<try> add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? `@bjorn3` try-job: x86_64-msvc try-job: i686-msvc try-job: i686-mingw try-job: x86_64-mingw

…isibility, r=bjorn3 add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? `@bjorn3`

…isibility, r=bjorn3 add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? ``@bjorn3``

Rollup merge of rust-lang#128362 - folkertdev:naked-function-symbol-visibility, r=bjorn3 add test for symbol visibility of `#[naked]` functions tracking issue: rust-lang#90957 This test is extracted from rust-lang#128004 That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration. In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function. Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress. Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something. r? ``@bjorn3``

chorman0773 · 2024-08-22T04:42:21Z

As a procedural question, I'd like to ask whether the stablization FCP above is still valid, given it's been ~2 years since it finished.

…tions, r=workingjubilee,compiler-errors add repr to the allowlist for naked functions Fixes rust-lang#129412 (combining unstable features rust-lang#90957 (`#![feature(naked_functions)]`) and rust-lang#82232 (`#![feature(fn_align)]`)

Rollup merge of rust-lang#129421 - jdonszelmann:naked-repr-align-functions, r=workingjubilee,compiler-errors add repr to the allowlist for naked functions Fixes rust-lang#129412 (combining unstable features rust-lang#90957 (`#![feature(naked_functions)]`) and rust-lang#82232 (`#![feature(fn_align)]`)

traviscross · 2024-09-03T21:09:19Z

As a procedural question, I'd like to ask whether the stablization FCP above is still valid, given it's been ~2 years since it finished.

That is an awfully long time ago. Please +I-lang-nominate the PR for stabilization and we'll make a call there about how it should proceed.

folkertdev · 2024-09-03T21:44:04Z

sure

@rustbot label +I-lang-nominated

for context, recent changes mostly implement changes suggested by @Amanieu. The main changes are

#[naked]: use an allowlist for allowed options on asm! in naked functions #128138 add an allowlist for what attributes can be used in combination with #[naked]. This got some followups for attributes that we cautiously omitted but are actually used and valid in combination with #[naked].
codegen #[naked] functions using global asm #128004 implement naked functions using global assembly. Versus using LLVM's naked attribute, we get more control, and don't need to do anything special for other backends (e.g. gcc and cranelift are a lot more relevant versus 2 years ago). I'll need some help with integrating this nicely into rustc_codegen_ssa.
add naked_asm! macro for use in #[naked] functions #128651 add a separate naked_asm! macro to generate the global assembly. This can have dedicated documentation, and clear rules. The alternative is to "abuse" asm!, but impose a weird mix of restrictions.

So far this design (still) looks good to me

traviscross · 2024-09-04T03:09:35Z

@rustbot labels -I-lang-nominated

@folkertdev: When I said please nominate the PR for stabilization, what I mean is, please make a pull request that stabilizes this feature (if you're ready to do that) (documentation here). In that PR, please include a stabilization report. You can start from the one here and update it with what has changed since then and why it's ready to stabilize now. Then please nominate that PR for lang.

…Amanieu bootstrap `naked_asm!` for `compiler-builtins` tracking issue: rust-lang#90957 parent PR: rust-lang#128651 in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later. The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in rust-lang#128651 I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR. r? `@Amanieu`

…Amanieu bootstrap `naked_asm!` for `compiler-builtins` tracking issue: rust-lang#90957 parent PR: rust-lang#128651 in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later. The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in rust-lang#128651 I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR. r? ``@Amanieu``

Rollup merge of rust-lang#130146 - folkertdev:bootstrap-naked-asm, r=Amanieu bootstrap `naked_asm!` for `compiler-builtins` tracking issue: rust-lang#90957 parent PR: rust-lang#128651 in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later. The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in rust-lang#128651 I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR. r? ``@Amanieu``

…n, r=<try> disallow `naked_asm!` outside of `#[naked]` functions tracking issue: rust-lang#90957 parent PR: rust-lang#128651 I split this out from the parent PR because it's self-contained and because the analysis has to search through all functions and there might be performance regressions. r? `@Amanieu`

bootstrap `naked_asm!` for `compiler-builtins` tracking issue: rust-lang/rust#90957 parent PR: rust-lang/rust#128651 in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later. The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in rust-lang/rust#128651 I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR. r? ``@Amanieu``

…n, r=Amanieu disallow `naked_asm!` outside of `#[naked]` functions tracking issue: rust-lang#90957 parent PR: rust-lang#128651 I split this out from the parent PR because it's self-contained and because the analysis has to search through all functions and there might be performance regressions. r? `@Amanieu`

disallow `naked_asm!` outside of `#[naked]` functions tracking issue: rust-lang/rust#90957 parent PR: rust-lang/rust#128651 I split this out from the parent PR because it's self-contained and because the analysis has to search through all functions and there might be performance regressions. r? `@Amanieu`

…nieu add `naked_asm!` macro for use in `#[naked]` functions tracking issue: rust-lang#90957 Adds the `core::arch::naked_asm` macro, to be used in `#[naked]` functions, but providing better error messages and a place to explain the restrictions on assembly in naked functions. This PR does not yet require that the `naked_asm!` macro is used inside of `#[naked]` functions: - the `asm!` macro can still be used in `#[naked]` functions currently, with the same restrictions and error messages as before. - the `naked_asm!` macro can be used outside of `#[naked]` functions. It has not yet been decided whether that should be allowed long-term. In this PR, the parsing code of `naked_asm!` now enforces the restrictions on assembly in naked functions, with the exception of checking that the `noreturn` option is specified. It also has not currently been decided if `noreturn` should be implicit or not. This PR looks large because it touches a bunch of tests. The code changes are mostly straightforward I think: we now have 3 flavors of assembly macro, and that information must be propagated through the parsing code and error messages. cc `@Lokathor` r? `@Amanieu`

nikomatsakis added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Nov 16, 2021

nikomatsakis mentioned this issue Nov 16, 2021

Constrained Naked Functions rust-lang/rfcs#2972

Merged

15 tasks

nikomatsakis added the F-naked_functions `#![feature(naked_functions)]` label Nov 16, 2021

bjorn3 mentioned this issue Nov 17, 2021

Implement naked functions rust-lang/rustc_codegen_cranelift#1203

Closed

joshtriplett mentioned this issue Jan 19, 2022

Tracking issue for naked fns (RFC #1201) #32408

Closed

bstrie self-assigned this Jan 25, 2022

bstrie mentioned this issue Jan 25, 2022

[Tracking]: Pursue stabilization for Rust RFC 2972: "Constrained Naked Functions" enarx/enarx#1269

Closed

1 task

bstrie mentioned this issue Feb 1, 2022

Add documentation for the naked function attribute rust-lang/reference#1153

Draft

bstrie added the A-naked Area: `#[naked]`, prologue and epilogue-free, functions, https://git.io/vAzzS label Feb 2, 2022

bstrie mentioned this issue Feb 2, 2022

Stabilize naked_functions #93587

Closed

bstrie added a commit to bstrie/rust that referenced this issue Feb 2, 2022

Stabilize naked_functions

34386b3

This stabilizes the feature described in RFC 2972, which supersedes the earlier RFC 1201. Closes rust-lang#32408 Closes rust-lang#90957

rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Feb 2, 2022

folkertdev mentioned this issue Aug 4, 2024

add naked_asm! macro for use in #[naked] functions #128651

Merged

This was referenced Aug 22, 2024

#[naked] attribute excludes use of #[repr(align(N))] #129412

Closed

add repr to the allowlist for naked functions #129421

Merged

rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Sep 3, 2024

rustbot removed the I-lang-nominated Nominated for discussion during a lang team meeting. label Sep 4, 2024

folkertdev mentioned this issue Sep 9, 2024

bootstrap naked_asm! for compiler-builtins #130146

Merged

This was referenced Sep 10, 2024

use naked_asm! in #[naked] functions rust-lang/compiler-builtins#686

Merged

disallow naked_asm! outside of #[naked] functions #130195

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for RFC #2972: Constrained Naked Functions #90957

Tracking Issue for RFC #2972: Constrained Naked Functions #90957

nikomatsakis commented Nov 16, 2021 •

edited by fmease

Loading

safinaskar commented Jan 23, 2022

bstrie commented Jan 25, 2022

bstrie commented Feb 2, 2022 •

edited

Loading

bjorn3 commented Feb 2, 2022

bstrie commented Feb 2, 2022 •

edited

Loading

roblabla commented Feb 2, 2022

joshtriplett commented Feb 2, 2022

joshtriplett commented Feb 2, 2022

rfcbot commented Feb 2, 2022 •

edited by scottmcm

Loading

Amanieu commented Feb 2, 2022

comex commented Feb 3, 2022

bjorn3 commented Feb 3, 2022

bstrie commented Feb 3, 2022

roblabla commented Feb 3, 2022 •

edited

Loading

chorman0773 commented Aug 22, 2024

traviscross commented Sep 3, 2024

folkertdev commented Sep 3, 2024

traviscross commented Sep 4, 2024

Tracking Issue for RFC #2972: Constrained Naked Functions #90957

Tracking Issue for RFC #2972: Constrained Naked Functions #90957

Comments

nikomatsakis commented Nov 16, 2021 • edited by fmease Loading

About tracking issues

Steps

Unresolved Questions

Implementation history

safinaskar commented Jan 23, 2022

bstrie commented Jan 25, 2022

bstrie commented Feb 2, 2022 • edited Loading

Request for Stabilization

Summary

Documentation

Tests

History

Unresolved Questions

bjorn3 commented Feb 2, 2022

bstrie commented Feb 2, 2022 • edited Loading

roblabla commented Feb 2, 2022

joshtriplett commented Feb 2, 2022

joshtriplett commented Feb 2, 2022

rfcbot commented Feb 2, 2022 • edited by scottmcm Loading

Amanieu commented Feb 2, 2022

comex commented Feb 3, 2022

bjorn3 commented Feb 3, 2022

bstrie commented Feb 3, 2022

roblabla commented Feb 3, 2022 • edited Loading

chorman0773 commented Aug 22, 2024

traviscross commented Sep 3, 2024

folkertdev commented Sep 3, 2024

traviscross commented Sep 4, 2024

nikomatsakis commented Nov 16, 2021 •

edited by fmease

Loading

bstrie commented Feb 2, 2022 •

edited

Loading

bstrie commented Feb 2, 2022 •

edited

Loading

rfcbot commented Feb 2, 2022 •

edited by scottmcm

Loading

roblabla commented Feb 3, 2022 •

edited

Loading