Skip to content

add extern "custom" functions #140770

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

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

folkertdev
Copy link
Contributor

@folkertdev folkertdev commented May 7, 2025

tracking issue: #140829
previous discussion: #140566

In short, an extern "custom" function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with #[unsafe(naked)] and naked_asm!, or via an extern "C" { /* ... */ } block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.

The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick extern "C", but that is a lie because the function does not actually respect the C calling convention.

At the moment "custom" seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.

r? @traviscross
cc @tgross35

try-job: x86_64-apple-2

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 7, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 7, 2025

These commits modify compiler targets.
(See the Target Tier Policy.)

@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented May 7, 2025

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bjorn3
Copy link
Member

bjorn3 commented May 8, 2025

Emit some extern "custom" errors in ast_validation:wq

Did you forget to press escape before quitting vim?

@folkertdev
Copy link
Contributor Author

ah, yeah. Well it'll probably get squashed before this is ready

@folkertdev
Copy link
Contributor Author

I've made a proper tracking issue at #140829

@bors
Copy link
Collaborator

bors commented May 17, 2025

☔ The latest upstream changes (presumably #141002) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Collaborator

bors commented Jun 4, 2025

☔ The latest upstream changes (presumably #141984) made this pull request unmergeable. Please resolve the merge conflicts.

@rust-bors
Copy link

rust-bors bot commented Jun 12, 2025

@folkertdev: 🔑 Insufficient privileges: not in try users

@folkertdev
Copy link
Contributor Author

maybe old bors works since it did the delegation?

@bors try

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

⌛ Trying commit 6351952 with merge 83eaabc...

bors added a commit that referenced this pull request Jun 12, 2025
add `extern "custom"` functions

tracking issue: #140829
previous discussion: #140566

In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.

The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.

At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.

r? `@traviscross`
cc `@tgross35`

try-job: x86_64-apple-2
@tgross35
Copy link
Contributor

If needed:
@bors2 delegte=try

@rust-bors
Copy link

rust-bors bot commented Jun 12, 2025

Unknown command "delegte".

@workingjubilee
Copy link
Member

@bors2 delegate=try

@rust-bors
Copy link

rust-bors bot commented Jun 12, 2025

@folkertdev can now perform try builds on this pull request

Comment on lines 15 to 22
global_asm!(
//
" .globl increment",
"increment:",
" add rax, 1",
" ret",
);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

btw the issue was that I used the .type and .size directives here, which don't work on macOS. I just removed them, which should be fine for test code.

Copy link
Contributor

Choose a reason for hiding this comment

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

You probably need the same label trick from here

@bors

This comment was marked as outdated.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@bjorn3
Copy link
Member

bjorn3 commented Jun 12, 2025

Mach-O prefixes symbol names defined in C (and by extension Rust) with an _. You could try using a sym operand referring to the unsafe extern "custom" { fn increment(); } declaration to ensure both sides agree on the symbol name.

@folkertdev
Copy link
Contributor Author

Oh, that's clever!

@bors try

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

⌛ Trying commit 5f73ce2 with merge 33aabc7...

bors added a commit that referenced this pull request Jun 12, 2025
add `extern "custom"` functions

tracking issue: #140829
previous discussion: #140566

In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.

The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.

At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.

r? `@traviscross`
cc `@tgross35`

try-job: x86_64-apple-2
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[TIMING] core::build_steps::test::Crate { compiler: Compiler { stage: 1, host: x86_64-unknown-linux-gnu, forced_compiler: true }, target: x86_64-unknown-linux-gnu, mode: Std, crates: ["std"] } -- 69.262
Build completed successfully in 0:01:12
+ head -n 1 /tmp/browser-ui-test.version
+ npm install browser-ui-test@0.20.6 --unsafe-perm=true
npm ERR! code E503
npm ERR! 503 Service Unavailable - GET https://registry.npmjs.org/@puppeteer/browsers/-/browsers-2.3.0.tgz - Service Unavailable

npm ERR! A complete log of this run can be found in: /root/.npm/_logs/2025-06-12T19_23_02_212Z-debug-0.log
  local time: Thu Jun 12 19:25:26 UTC 2025
  network time: Thu, 12 Jun 2025 19:25:26 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

@tgross35
Copy link
Contributor

^ pretty widespread internet outages going on right now, including npm

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

☀️ Try build successful - checks-actions
Build commit: 33aabc7 (33aabc703ff3ae8fd55fe25c96b5461fb8601fca)

@folkertdev
Copy link
Contributor Author

Looks like the job that failed with the npm stuff got re-run? In any case, it's green now, the try build worked, so

@bors r=@tgross35

@bors
Copy link
Collaborator

bors commented Jun 12, 2025

📌 Commit 5f73ce2 has been approved by tgross35

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 12, 2025
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jun 13, 2025
add `extern "custom"` functions

tracking issue: rust-lang#140829
previous discussion: rust-lang#140566

In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.

The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.

At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.

r? `@traviscross`
cc `@tgross35`

try-job: x86_64-apple-2
bors added a commit that referenced this pull request Jun 13, 2025
Rollup of 9 pull requests

Successful merges:

 - #128425 (Make `missing_fragment_specifier` an unconditional error)
 - #135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features)
 - #140770 (add `extern "custom"` functions)
 - #142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches)
 - #142248 (Add supported asm types for LoongArch32)
 - #142267 (assert more in release in `rustc_ast_lowering`)
 - #142274 (Update the stdarch submodule)
 - #142276 (Update dependencies in `library/Cargo.lock`)
 - #142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library)

Failed merges:

 - #140920 (Extract some shared code from codegen backend target feature handling)

r? `@ghost`
`@rustbot` modify labels: rollup

try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ABI Area: Concerning the application binary interface (ABI) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. A-naked Area: `#[naked]`, prologue and epilogue-free, functions, https://git.io/vAzzS S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.