-
Notifications
You must be signed in to change notification settings - Fork 13.4k
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
add extern "custom"
functions
#140770
Conversation
These commits modify compiler targets. |
This comment has been minimized.
This comment has been minimized.
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred in compiler/rustc_codegen_gcc |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Did you forget to press escape before quitting vim? |
ah, yeah. Well it'll probably get squashed before this is ready |
I've made a proper tracking issue at #140829 |
☔ The latest upstream changes (presumably #141002) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #141984) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Mach-O prefixes symbol names defined in C (and by extension Rust) with an |
Oh, that's clever! @bors try |
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
The job Click to see the possible cause of the failure (guessed by this bot)
|
^ pretty widespread internet outages going on right now, including npm |
☀️ Try build successful - checks-actions |
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
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
Rollup merge of #140770 - folkertdev:custom-abi, r=tgross35 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
Rollup of 9 pull requests Successful merges: - rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang/rust#140770 (add `extern "custom"` functions) - rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang/rust#142248 (Add supported asm types for LoongArch32) - rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang/rust#142274 (Update the stdarch submodule) - rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang/rust#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
Rollup of 9 pull requests Successful merges: - rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang/rust#140770 (add `extern "custom"` functions) - rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang/rust#142248 (Add supported asm types for LoongArch32) - rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang/rust#142274 (Update the stdarch submodule) - rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang/rust#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
Rollup of 9 pull requests Successful merges: - rust-lang/rust#128425 (Make `missing_fragment_specifier` an unconditional error) - rust-lang/rust#135927 (retpoline and retpoline-external-thunk flags (target modifiers) to enable retpoline-related target features) - rust-lang/rust#140770 (add `extern "custom"` functions) - rust-lang/rust#142176 (tests: Split dont-shuffle-bswaps along opt-levels and arches) - rust-lang/rust#142248 (Add supported asm types for LoongArch32) - rust-lang/rust#142267 (assert more in release in `rustc_ast_lowering`) - rust-lang/rust#142274 (Update the stdarch submodule) - rust-lang/rust#142276 (Update dependencies in `library/Cargo.lock`) - rust-lang/rust#142308 (Upgrade `object`, `addr2line`, and `unwinding` in the standard library) Failed merges: - rust-lang/rust#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
@rust-timer build 2bf564a (Testing #142443) |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (2bf564a): comparison URL. Overall result: no relevant changes - no action neededBenchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf. @bors rollup=never Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 2.0%, secondary -1.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 2.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 755.964s -> 690.275s (-8.69%) |
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)]
andnaked_asm!
, or via anextern "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