rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
359bfa901b9d8eddbed7b88b6716dbb77b7bfb95
rust/tests/ui/abi/unsupported.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

139 lines
4.8 KiB
Rust
Raw Normal View History

tests: use minicore more minicore makes it much easier to add new language items to all of the existing `no_core` tests.
2025-02-24 09:26:54 +00:00
//@ add-core-stubs
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
//@ revisions: x64 x64_win i686 aarch64 arm riscv32 riscv64
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
//
//@ [x64] needs-llvm-components: x86
Disallow the aapcs CC on Aarch64 This never really worked and makes LLVM assert.
2021-08-27 19:36:18 +03:00
//@ [x64] compile-flags: --target=x86_64-unknown-linux-gnu --crate-type=rlib
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
//@ [x64_win] needs-llvm-components: x86
//@ [x64_win] compile-flags: --target=x86_64-pc-windows-msvc --crate-type=rlib
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
//@ [i686] needs-llvm-components: x86
Disallow the aapcs CC on Aarch64 This never really worked and makes LLVM assert.
2021-08-27 19:36:18 +03:00
//@ [i686] compile-flags: --target=i686-unknown-linux-gnu --crate-type=rlib
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
//@ [aarch64] needs-llvm-components: aarch64
Disallow the aapcs CC on Aarch64 This never really worked and makes LLVM assert.
2021-08-27 19:36:18 +03:00
//@ [aarch64] compile-flags: --target=aarch64-unknown-linux-gnu --crate-type=rlib
//@ [arm] needs-llvm-components: arm
//@ [arm] compile-flags: --target=armv7-unknown-linux-gnueabihf --crate-type=rlib
feat: `riscv-interrupt-{m,s}` calling conventions Similar to prior support added for the mips430, avr, and x86 targets this change implements the rough equivalent of clang's [`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling e.g. ```rust static mut CNT: usize = 0; pub extern "riscv-interrupt-m" fn isr_m() { unsafe { CNT += 1; } } ``` to produce highly effective assembly like: ```asm pub extern "riscv-interrupt-m" fn isr_m() { 420003a0: 1141 addi sp,sp,-16 unsafe { CNT += 1; 420003a2: c62a sw a0,12(sp) 420003a4: c42e sw a1,8(sp) 420003a6: 3fc80537 lui a0,0x3fc80 420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0> 420003ae: 0585 addi a1,a1,1 420003b0: 62b52e23 sw a1,1596(a0) } } 420003b4: 4532 lw a0,12(sp) 420003b6: 45a2 lw a1,8(sp) 420003b8: 0141 addi sp,sp,16 420003ba: 30200073 mret ``` (disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`) This outcome is superior to hand-coded interrupt routines which, lacking visibility into any non-assembly body of the interrupt handler, have to be very conservative and save the [entire CPU state to the stack frame][full-frame-save]. By instead asking LLVM to only save the registers that it uses, we defer the decision to the tool with the best context: it can more accurately account for the cost of spills if it knows that every additional register used is already at the cost of an implicit spill. At the LLVM level, this is apparently [implemented by] marking every register as "[callee-save]," matching the semantics of an interrupt handler nicely (it has to leave the CPU state just as it found it after its `{m|s}ret`). This approach is not suitable for every interrupt handler, as it makes no attempt to e.g. save the state in a user-accessible stack frame. For a full discussion of those challenges and tradeoffs, please refer to [the interrupt calling conventions RFC][rfc]. Inside rustc, this implementation differs from prior art because LLVM does not expose the "all-saved" function flavor as a calling convention directly, instead preferring to use an attribute that allows for differentiating between "machine-mode" and "superivsor-mode" interrupts. Finally, some effort has been made to guide those who may not yet be aware of the differences between machine-mode and supervisor-mode interrupts as to why no `riscv-interrupt` calling convention is exposed through rustc, and similarly for why `riscv-interrupt-u` makes no appearance (as it would complicate future LLVM upgrades). [clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v [full-frame-save]: https://github.com/esp-rs/esp-riscv-rt/blob/9281af2ecffe13e40992917316f36920c26acaf3/src/lib.rs#L440-L469 [implemented by]: https://github.com/llvm/llvm-project/blob/b7fb2a3fec7c187d58a6d338ab512d9173bca987/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp#L61-L67 [callee-save]: https://github.com/llvm/llvm-project/blob/973f1fe7a8591c7af148e573491ab68cc15b6ecf/llvm/lib/Target/RISCV/RISCVCallingConv.td#L30-L37 [rfc]: https://github.com/rust-lang/rfcs/pull/3246
2023-05-23 15:08:23 -07:00
//@ [riscv32] needs-llvm-components: riscv
//@ [riscv32] compile-flags: --target=riscv32i-unknown-none-elf --crate-type=rlib
//@ [riscv64] needs-llvm-components: riscv
//@ [riscv64] compile-flags: --target=riscv64gc-unknown-none-elf --crate-type=rlib
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
#![no_core]
#![feature(
no_core,
lang_items,
abi_ptx,
abi_msp430_interrupt,
abi_avr_interrupt,
Add gpu-kernel calling convention The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
2025-01-02 22:42:10 +01:00
abi_gpu_kernel,
feat: `riscv-interrupt-{m,s}` calling conventions Similar to prior support added for the mips430, avr, and x86 targets this change implements the rough equivalent of clang's [`__attribute__((interrupt))`][clang-attr] for riscv targets, enabling e.g. ```rust static mut CNT: usize = 0; pub extern "riscv-interrupt-m" fn isr_m() { unsafe { CNT += 1; } } ``` to produce highly effective assembly like: ```asm pub extern "riscv-interrupt-m" fn isr_m() { 420003a0: 1141 addi sp,sp,-16 unsafe { CNT += 1; 420003a2: c62a sw a0,12(sp) 420003a4: c42e sw a1,8(sp) 420003a6: 3fc80537 lui a0,0x3fc80 420003aa: 63c52583 lw a1,1596(a0) # 3fc8063c <_ZN12esp_riscv_rt3CNT17hcec3e3a214887d53E.0> 420003ae: 0585 addi a1,a1,1 420003b0: 62b52e23 sw a1,1596(a0) } } 420003b4: 4532 lw a0,12(sp) 420003b6: 45a2 lw a1,8(sp) 420003b8: 0141 addi sp,sp,16 420003ba: 30200073 mret ``` (disassembly via `riscv64-unknown-elf-objdump -C -S --disassemble ./esp32c3-hal/target/riscv32imc-unknown-none-elf/release/examples/gpio_interrupt`) This outcome is superior to hand-coded interrupt routines which, lacking visibility into any non-assembly body of the interrupt handler, have to be very conservative and save the [entire CPU state to the stack frame][full-frame-save]. By instead asking LLVM to only save the registers that it uses, we defer the decision to the tool with the best context: it can more accurately account for the cost of spills if it knows that every additional register used is already at the cost of an implicit spill. At the LLVM level, this is apparently [implemented by] marking every register as "[callee-save]," matching the semantics of an interrupt handler nicely (it has to leave the CPU state just as it found it after its `{m|s}ret`). This approach is not suitable for every interrupt handler, as it makes no attempt to e.g. save the state in a user-accessible stack frame. For a full discussion of those challenges and tradeoffs, please refer to [the interrupt calling conventions RFC][rfc]. Inside rustc, this implementation differs from prior art because LLVM does not expose the "all-saved" function flavor as a calling convention directly, instead preferring to use an attribute that allows for differentiating between "machine-mode" and "superivsor-mode" interrupts. Finally, some effort has been made to guide those who may not yet be aware of the differences between machine-mode and supervisor-mode interrupts as to why no `riscv-interrupt` calling convention is exposed through rustc, and similarly for why `riscv-interrupt-u` makes no appearance (as it would complicate future LLVM upgrades). [clang-attr]: https://clang.llvm.org/docs/AttributeReference.html#interrupt-risc-v [full-frame-save]: https://github.com/esp-rs/esp-riscv-rt/blob/9281af2ecffe13e40992917316f36920c26acaf3/src/lib.rs#L440-L469 [implemented by]: https://github.com/llvm/llvm-project/blob/b7fb2a3fec7c187d58a6d338ab512d9173bca987/llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp#L61-L67 [callee-save]: https://github.com/llvm/llvm-project/blob/973f1fe7a8591c7af148e573491ab68cc15b6ecf/llvm/lib/Target/RISCV/RISCVCallingConv.td#L30-L37 [rfc]: https://github.com/rust-lang/rfcs/pull/3246
2023-05-23 15:08:23 -07:00
abi_x86_interrupt,
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
abi_riscv_interrupt,
tests: s/C-cmse/cmse/
2025-06-06 23:07:41 -07:00
abi_cmse_nonsecure_call,
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
abi_vectorcall,
Also cover the new `extern "C-cmse-nonsecure-entry"` in tests
2024-09-23 14:15:20 +02:00
cmse_nonsecure_entry
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
)]
tests: use minicore more minicore makes it much easier to add new language items to all of the existing `no_core` tests.
2025-02-24 09:26:54 +00:00
extern crate minicore;
use minicore::*;
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
extern "ptx-kernel" fn ptx() {}
//~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
fn ptx_ptr(f: extern "ptx-kernel" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
f()
}
extern "ptx-kernel" {}
//~^ ERROR is not a supported ABI
Add gpu-kernel calling convention The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
2025-01-02 22:42:10 +01:00
extern "gpu-kernel" fn gpu() {}
//~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
extern "aapcs" fn aapcs() {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,i686,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
fn aapcs_ptr(f: extern "aapcs" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//[x64,x64_win,i686,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
f()
}
extern "aapcs" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,i686,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
extern "msp430-interrupt" {}
//~^ ERROR is not a supported ABI
extern "avr-interrupt" {}
//~^ ERROR is not a supported ABI
extern "riscv-interrupt-m" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,i686,arm,aarch64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
extern "x86-interrupt" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[aarch64,arm,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
Replace per-target ABI denylist with an allowlist It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai
2021-06-11 14:22:13 +03:00
extern "thiscall" fn thiscall() {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
fn thiscall_ptr(f: extern "thiscall" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
f()
}
extern "thiscall" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
make thiscall on unsupported platforms an error
2021-10-24 11:57:45 -07:00
extern "stdcall" fn stdcall() {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
//[x64_win]~^^ WARN unsupported_calling_conventions
//[x64_win]~^^^ WARN this was previously accepted
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
fn stdcall_ptr(f: extern "stdcall" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//[x64,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
//[x64_win]~^^ WARN unsupported_calling_conventions
//[x64_win]~| WARN this was previously accepted
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
f()
}
extern "stdcall" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
//[x64_win]~^^ WARN unsupported_calling_conventions
//[x64_win]~^^^ WARN this was previously accepted
add specific help messages for stdcall and cdecl
2025-05-29 12:10:14 +02:00
extern "stdcall-unwind" {}
//[x64,arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
//[x64_win]~^^ WARN unsupported_calling_conventions
//[x64_win]~^^^ WARN this was previously accepted
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
extern "cdecl" fn cdecl() {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ WARN unsupported_calling_conventions
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^^ WARN this was previously accepted
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
fn cdecl_ptr(f: extern "cdecl" fn()) {
tests: bless unsupported_calling_conventions linting on some fn_ptrs
2025-06-09 15:50:01 -07:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ WARN unsupported_calling_conventions
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~| WARN this was previously accepted
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
f()
}
extern "cdecl" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ WARN unsupported_calling_conventions
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^^ WARN this was previously accepted
add specific help messages for stdcall and cdecl
2025-05-29 12:10:14 +02:00
extern "cdecl-unwind" {}
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^ WARN unsupported_calling_conventions
//[x64,x64_win,arm,aarch64,riscv32,riscv64]~^^ WARN this was previously accepted
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
extern "vectorcall" fn vectorcall() {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
fn vectorcall_ptr(f: extern "vectorcall" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//[arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
add (back) unsupported_calling_conventions lint to reject more invalid calling conventions
2025-05-23 12:24:55 +02:00
f()
}
extern "vectorcall" {}
avoid repeating error annotations in test file
2025-05-23 14:22:55 +02:00
//[arm,aarch64,riscv32,riscv64]~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
tests: s/C-cmse/cmse/
2025-06-06 23:07:41 -07:00
fn cmse_call_ptr(f: extern "cmse-nonsecure-call" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//~^ ERROR is not a supported ABI
Check ABI target compatibility for function pointers This check was previously only performed on functions not function pointers. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-08-07 15:48:16 +02:00
f()
}
Also cover the new `extern "C-cmse-nonsecure-entry"` in tests
2024-09-23 14:15:20 +02:00
tests: s/C-cmse/cmse/
2025-06-06 23:07:41 -07:00
extern "cmse-nonsecure-entry" fn cmse_entry() {}
Also cover the new `extern "C-cmse-nonsecure-entry"` in tests
2024-09-23 14:15:20 +02:00
//~^ ERROR is not a supported ABI
tests: s/C-cmse/cmse/
2025-06-06 23:07:41 -07:00
fn cmse_entry_ptr(f: extern "cmse-nonsecure-entry" fn()) {
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//~^ ERROR is not a supported ABI
Also cover the new `extern "C-cmse-nonsecure-entry"` in tests
2024-09-23 14:15:20 +02:00
f()
}
tests: s/C-cmse/cmse/
2025-06-06 23:07:41 -07:00
extern "cmse-nonsecure-entry" {}
Also cover the new `extern "C-cmse-nonsecure-entry"` in tests
2024-09-23 14:15:20 +02:00
//~^ ERROR is not a supported ABI
raw dylib: ensure that we have applied standard ABI checks also unify error messages that do not seem to have a good reason to be different
2025-05-23 12:44:15 +02:00
#[cfg(windows)]
#[link(name = "foo", kind = "raw-dylib")]
extern "cdecl" {}
tests: Enhance unsupported ABI tests We have fairly different error messages now and handle more cases, so we augment the test in tests/ui/abi/unsupported.rs with more examples to handle structs, traits, and impls on same when those feature the unsupported ABIs of interest.
2025-06-13 12:37:55 -07:00
//[x64_win]~^ WARN unsupported_calling_conventions
raw dylib: ensure that we have applied standard ABI checks also unify error messages that do not seem to have a good reason to be different
2025-05-23 12:44:15 +02:00
//[x64_win]~^^ WARN this was previously accepted
Reference in New Issue Copy Permalink