Stabilize extern "custom" - #158504
Open
folkertdev wants to merge 1 commit into
Open
Conversation
rustbot
added
A-compiler-builtins
Contributor
Author
|
r? tgross35 |
Collaborator
|
|
folkertdev
marked this pull request as ready for review
June 28, 2026 15:33
rustbot
added
the
S-waiting-on-review
Collaborator
|
cc @tgross35 |
rustbot
removed
the
S-waiting-on-author
folkertdev
added
the
I-lang-nominated
This comment has been minimized.
This comment has been minimized.
Member
|
Do we deny this on wasm? Wasm requires the function signature to be known when defining or importing it. |
Contributor
Author
|
In that case, does the whole concept of a naked function even make sense there? That is, can it do something that a normal function whose body is an Practically inline assembly is unstable (and extremely incomplete) for wasm, so I'm not sure if/how it'll eventually fit in. But we can deny |
Member
|
Naked asm can avoid touching the stack, maybe there are cases that is useful? Naked asm doesn't help for defining functions that use ref types or GC types as there isn't a way to express those using rust syntax, so those still need |
Contributor
|
Allowing only assembly calls seems quite restrictive in terms of cross platform capabilities, as a special case, an |
Contributor
|
This is a restriction on |
Contributor
Author
|
Just making this explicit: #158621 removes support for wasm and spirv targets. Neither have stable assembly, so practically this doesn't change anything, but the whole concept of |
4 tasks
traviscross
added
needs-reference-pr
Contributor
|
Makes sense to me. Thanks @folkertdev for your work on this. @rfcbot fcp merge lang cc @Amanieu |
Collaborator
|
@traviscross has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
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! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
rust-rfcbot
added
proposed-final-comment-period
rust-rfcbot
added
finished-final-comment-period
Collaborator
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
folkertdev
force-pushed
the
stabilize-extern-custom
branch
from
July 29, 2026 12:44
2beadda to
e50eeac
Compare
This comment has been minimized.
This comment has been minimized.
folkertdev
force-pushed
the
stabilize-extern-custom
branch
from
July 29, 2026 12:53
e50eeac to
5e6a3e9
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
folkertdev
force-pushed
the
stabilize-extern-custom
branch
from
July 29, 2026 13:35
5e6a3e9 to
8436fc4
Compare
Contributor
|
Looks like a pretty trivial stabilization but this needs the RFC rust-lang/rfcs#3980. @rustbot blocked @SnoozeThis rust-lang/rfcs#3980 -> remove label S-blocked, add label S-waiting-on-review |
rustbot
added
S-blocked
folkertdev
added
S-waiting-on-review
Contributor
Author
|
The RFC has been merged and the reference PR has been approved. |
This comment has been minimized.
This comment has been minimized.
folkertdev
force-pushed
the
stabilize-extern-custom
branch
from
August 8, 2026 11:54
8436fc4 to
364b5d7
Compare
Collaborator
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Contributor
|
It looks like we currently accept generics, this currently builds: #![feature(abi_custom)]
use std::arch::naked_asm;
#[unsafe(naked)]
unsafe extern "custom" fn increment<T>() {
naked_asm!(
"add rax, 1",
"ret",
)
}https://rust.godbolt.org/z/cv77sYnqE: I think we should reject this for the same reason we reject arguments. @rust-lang/lang to confirm |
Contributor
|
Changing my mind here, I can see valid usecases for something like: #![feature(abi_custom)]
use std::arch::asm;
use std::arch::naked_asm;
/// # Safety
/// Something about ABI and overflow...
#[unsafe(naked)]
unsafe extern "custom" fn increment<T, const N: usize>() {
naked_asm!(
"add rax, {x}",
"add rax, {N}",
"ret",
x = const size_of::<T>(),
N = const N,
)
}
fn main() {
let mut x: u64 = 0;
unsafe {
asm!(
"call {}",
sym increment::<u32, 10>,
inout("rax") x,
);
}
assert_eq!(x, 4);
}https://rust.godbolt.org/z/odj6Tcsbd But lang still needs to weigh in since this didn't come up in the RFC or reference PR as far as I can tell. @rustbot label +I-lang-nominated Edit: I see we actually test for this already, at least with const generics Lines 48 to 54 in 4667d75 |
rustbot
added
the
I-lang-nominated
Contributor
|
Second question: should we reject Currently accepted https://rust.godbolt.org/z/rh5aMbcGK |
tgross35
reviewed
Aug 9, 2026
Contributor
There was a problem hiding this comment.
Some small test suggestions, otherwise stabilization looks fine to me against rust-lang/reference#2300 at 66b3bc5b8688 with the possible exception of generics and #[cold]. I guess generics are probably fine, would just like somebody from lang to confirm since I haven't seen it discussed anywhere.
Contributor
There was a problem hiding this comment.
Since the docs say returning the unit type is okay, it would be good to add a -> () and -> SomeAlias to make sure that actually works and it's not an AST gate (seems like it is fine)
Contributor
Author
There was a problem hiding this comment.
No it is an AST gate, the alias fails https://godbolt.org/z/G35o3EGW6.
Doing it truly based on the type is all kinds of nasty in the case of generics
trait MyTrait {
type T;
#[unsafe(naked)]
unsafe extern "custom" foo() -> Self::T { // error?
core::arch::asm!("");
}
}We also lose span information about the function header I believe, so it would be harder go generate a good error message if we delay.
| "ret", | ||
| const N, | ||
| ); | ||
| } |
Contributor
There was a problem hiding this comment.
Wouldn't hurt to have something similar for non-const generics
Contributor
|
Thanks @tgross35 for flagging those. For my own part, I agree that generics should be accepted and that |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
View all comments
tracking issue: #140829
reference PR: rust-lang/reference#2300
closes #140829
Summary
An
extern "custom" fnis a function with a custom ABI that is unknown to rust. Often these are low-level functions that pass arguments in different registers than any standard calling convention.Design
Because rust doesn't know what calling convention to use, an
extern "custom"function can only be called via inline assembly or FFI.An
extern "custom"function definition must be a naked function:An
extern "custom"function definition must be unsafe. The intent here is that a safety comment is written on how this function may be called.In an
extern "custom"block, functions cannot be marked assafe:An
extern "custom"function cannot have any arguments or a return type:Tests
extern "custom"function gives an error, etc.History
extern "unspecified"for naked functions with arbitrary ABI #140566abi_custom#140829extern "custom"functions #140770extern "custom"function pointers #159780unresolved questions
None