rust/tests/ui/c-variadic, branch perf-tmphttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=perf-tmp2025-09-26T13:33:48+00:00Ignore more failing ui tests for GCC backend2025-09-26T13:33:48+00:00Guillaume Gomezguillaume1.gomez@gmail.com2025-09-26T11:59:06+00:00urn:sha1:a535c7be5444fb6584eecc99f53e6cdb710ff70fRollup merge of #146434 - folkertdev:c-variadic-inherent-methods, r=workingjubilee2025-09-18T15:20:56+00:00Matthias Krüger476013+matthiaskrgr@users.noreply.github.com2025-09-18T15:20:56+00:00urn:sha1:185926c99f34985f1823b1f085ef6f446a5ee4f3
c-variadic: allow c-variadic inherent and trait methods
tracking issue: https://github.com/rust-lang/rust/issues/44930
Continuing the work of https://github.com/rust-lang/rust/pull/146342, allow inherent and trait methods to be c-variadic. However, a trait that contains a c-variadic method is no longer dyn-compatible.
There is, presumably, some way to make c-variadic methods dyn-compatible. However currently, we don't have confidence that it'll work reliably: when methods from a `dyn` object are cast to a function pointer, a `ReifyShim` is created. If that shim is c-variadic, it would need to forward the C variable argument list.
That does appear to work, because the `va_list` is not represented in MIR at all in this case, so the registers from the call site are untouched by the shim and can be read by the actual implementation. That just does not seem like a solid implementation.
Also, intuitively, why would c-variadic function, primarily needed for FFI, need to be used with `dyn` objects at all? We can revisit this limitation if a need arises.
r? `@workingjubilee`
Detect top-level `...` in argument type2025-09-16T18:38:08+00:00Esteban Küberesteban@osdyne.com2025-09-16T18:38:08+00:00urn:sha1:e9270e3cba3da56d4d83ed74f648e53b041cb263
When writing something like the expression `|_: ...| {}`, we now detect the `...` during parsing explicitly instead of relying on the detection in `parse_ty_common` so that we don't talk about "nested `...` are not supported".
```
error: unexpected `...`
--> $DIR/no-closure.rs:6:35
|
LL | const F: extern "C" fn(...) = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
Reword note2025-09-16T18:24:51+00:00Esteban Küberesteban@osdyne.com2025-09-16T18:24:51+00:00urn:sha1:8306a2f02e6c56447ff05b19b4b73c5c861e34fdFix existing test2025-09-15T10:10:27+00:00Esteban Küberesteban@osdyne.com2025-09-15T10:10:27+00:00urn:sha1:a84c8deb1f61e020e026e1fa53bc613426da8fdbc-variadic: test `...` with naked functions2025-09-13T19:05:12+00:00Folkert de Vriesfolkert@folkertdev.nl2025-09-13T18:49:21+00:00urn:sha1:a84bb32e05d7dfa069ead63e90816e1833f107c9c-variadic: test that unsupported c-variadic ABIs are reported correctly2025-09-11T21:55:45+00:00Folkert de Vriesfolkert@folkertdev.nl2025-09-11T21:52:04+00:00urn:sha1:321a76b5f95325f20c9e88e87bfb4ddf536b6950c-variadic: allow trait methods to be c-variadic2025-09-11T08:27:28+00:00Folkert de Vriesfolkert@folkertdev.nl2025-09-10T15:53:41+00:00urn:sha1:01e83adc88653123fee444fdb930c16dd08da82d
but a C-variadic method makes a trait dyn-incompatible. That is because
methods from dyn traits, when cast to a function pointer, create a shim.
That shim can't really forward the c-variadic arguments.
c-variadic: allow inherent methods to be c-variadic2025-09-11T08:18:48+00:00Folkert de Vriesfolkert@folkertdev.nl2025-09-09T22:17:22+00:00urn:sha1:fd48528d185f59f60e301bce1e01d670ff4bdb30c-variadic: reject functions with unsupported extern ABI2025-09-09T19:38:38+00:00Folkert de Vriesfolkert@folkertdev.nl2025-09-08T17:27:07+00:00urn:sha1:9196844f0d86242ee3d6a446fe681b6b2d2d674c