`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks #143619

beetrees · 2025-07-07T23:13:17Z

This PR makes ... arguments without a pattern in non-foreign functions (such as the argument in unsafe extern "C" fn f(...) {}) a future-compatibility warning; making this error would be consistent with how unsafe extern "C" fn f(u32) {} is handled. Allowing ... arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the ... parameter is never named and instead calling va_start is required; disallowing ... arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. ... arguments without a pattern in extern blocks (such as unsafe extern "C" { fn f(...); }) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations).

As all the syntax gating for c_variadic has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0:

#[cfg(any())] // Equivalent to the more recent #[cfg(false)]
unsafe extern "C" fn bar(_: u32, ...) {}

Since this is more or less a stability hole and a Crater run shows only the binrw crate is using this, I think it would be ok to break this. This will require a lang FCP.

The idea of rejecting ... pre-expansion was first raised here #143546 (comment).

Tracking issue: #44930
cc @folkertdev @workingjubilee
r? @joshtriplett

rustbot · 2025-07-07T23:13:22Z

joshtriplett is not on the review rotation at the moment.
They may take a while to respond.

rustbot · 2025-07-08T01:36:41Z

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

compiler-errors · 2025-07-08T01:58:44Z

@bors2 try

for the crater

rust-bors · 2025-07-08T01:58:46Z

Unknown command "tryfor".

beetrees · 2025-07-08T16:45:27Z

Unknown command "tryfor".

@compiler-errors

compiler-errors · 2025-07-08T16:46:07Z

wild

@bors2 try

`c_variadic`: Make `fn f(...) {}` error like `fn f(u32) {}` outside of `extern` blocks This PR makes unnamed `...` parameters (such as the one in `unsafe extern "C" fn f(...) {}`) a parse error to be consistent with `unsafe extern "C" fn f(u32) {}`: this is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing unnamed `...` parameters also improves the overall consistency of the Rust language by matching the treatment of other unnamed parameters. Unnamed `...` parameters in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations). As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0: ```rust #[cfg(any())] // Equivalent to the more recent #[cfg(false)] unsafe extern "C" fn bar(_: u32, ...) {} ``` Since this is more or less a stability hole and is unlikely to be used in practice, I think it would be ok to break this, but this will definitely require both a crater check run and a lang FCP. Tracking issue: #44930 cc `@folkertdev` `@workingjubilee` r? `@joshtriplett`

rust-bors · 2025-07-08T16:46:12Z

⌛ Trying commit e18dc17 with merge e784c10…

To cancel the try build, run the command @bors2 try cancel.

rust-bors · 2025-07-08T19:02:57Z

☀️ Try build successful (CI)
Build commit: e784c10 (e784c10fc2dd34bf2bb7b1e51117e35d3f9c5837, parent: 040e2f8b9ff2d76fbe2146d6003e297ed4532088)

folkertdev · 2025-07-13T21:29:13Z

So, should we start that crater run here?

beetrees · 2025-07-14T21:27:25Z

@compiler-errors could you @craterbot check?

compiler-errors · 2025-07-14T21:28:44Z

👍

@craterbot check

craterbot · 2025-07-14T21:29:11Z

👌 Experiment pr-143619 created and queued.
🤖 Automatically detected try build e784c10
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-07-17T07:11:54Z

🚧 Experiment pr-143619 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-07-18T08:27:58Z

🚨 Report generation of pr-143619 failed: timed out waiting for connection
🛠️ If the error is fixed use the retry-report command.

🆘 If you need assistance dealing with this failure, please ask in t-infra on Zulip
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

folkertdev · 2025-07-19T10:02:45Z

not sure I have the permissions for this, but let's attempt

@craterbot retry-report

craterbot · 2025-07-19T10:02:47Z

🛠️ Generation of the report for pr-143619 queued again.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-07-19T11:00:50Z

🚨 Report generation of pr-143619 failed: timed out waiting for connection
🛠️ If the error is fixed use the retry-report command.

🆘 If you need assistance dealing with this failure, please ask in t-infra on Zulip
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

folkertdev · 2025-07-19T15:04:19Z

let's try again with rust-lang/crater#787 merged

@craterbot retry-report

craterbot · 2025-07-19T15:04:21Z

🛠️ Generation of the report for pr-143619 queued again.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2025-07-19T17:43:27Z

🎉 Experiment pr-143619 is completed!
📊 183 regressed and 4 fixed (664923 total)
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

…without a pattern outside of `extern` blocks

rustbot · 2025-11-10T13:34:20Z

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.

folkertdev · 2025-11-10T15:35:45Z

Thanks for the review!

@bors r=jdonszelmann

bors · 2025-11-10T15:35:48Z

📌 Commit 02e1f44 has been approved by jdonszelmann

It is now in the queue for this repository.

…mann `c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations). As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0: ```rust #[cfg(any())] // Equivalent to the more recent #[cfg(false)] unsafe extern "C" fn bar(_: u32, ...) {} ``` Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP. The idea of rejecting `...` pre-expansion was first raised here rust-lang#143546 (comment). Tracking issue: rust-lang#44930 cc `@folkertdev` `@workingjubilee` r? `@joshtriplett`

…mann `c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations). As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0: ```rust #[cfg(any())] // Equivalent to the more recent #[cfg(false)] unsafe extern "C" fn bar(_: u32, ...) {} ``` Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP. The idea of rejecting `...` pre-expansion was first raised here rust-lang#143546 (comment). Tracking issue: rust-lang#44930 cc ``@folkertdev`` ``@workingjubilee`` r? ``@joshtriplett``

…mann `c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations). As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0: ```rust #[cfg(any())] // Equivalent to the more recent #[cfg(false)] unsafe extern "C" fn bar(_: u32, ...) {} ``` Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP. The idea of rejecting `...` pre-expansion was first raised here rust-lang#143546 (comment). Tracking issue: rust-lang#44930 cc ```@folkertdev``` ```@workingjubilee``` r? ```@joshtriplett```

Rollup of 16 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147952 (Add a timeout to the `remote-test-client` connection) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup

`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations). As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0: ```rust #[cfg(any())] // Equivalent to the more recent #[cfg(false)] unsafe extern "C" fn bar(_: u32, ...) {} ``` Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP. The idea of rejecting `...` pre-expansion was first raised here #143546 (comment). Tracking issue: #44930 cc `@folkertdev` `@workingjubilee` r? `@joshtriplett`

bors · 2025-11-11T09:52:03Z

⌛ Testing commit 02e1f44 with merge 3e7e62b...

Zalathar · 2025-11-11T10:10:38Z

Yielding to enclosing rollup.

@bors retry

Rollup of 15 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #143619 - beetrees:varargs-named, r=jdonszelmann `c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations). As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0: ```rust #[cfg(any())] // Equivalent to the more recent #[cfg(false)] unsafe extern "C" fn bar(_: u32, ...) {} ``` Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP. The idea of rejecting `...` pre-expansion was first raised here #143546 (comment). Tracking issue: #44930 cc `@folkertdev` `@workingjubilee` r? `@joshtriplett`

Rollup of 15 pull requests Successful merges: - rust-lang/rust#141470 (Add new `function_casts_as_integer` lint) - rust-lang/rust#143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - rust-lang/rust#146495 (rustdoc: Erase `#![doc(document_private_items)]`) - rust-lang/rust#147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - rust-lang/rust#147833 (rustdoc-json: move `target` to `json::conversions`) - rust-lang/rust#147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - rust-lang/rust#148480 (Add `Steal::risky_hack_borrow_mut`) - rust-lang/rust#148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - rust-lang/rust#148508 (Provide more context when mutably borrowing an imutably borrowed value) - rust-lang/rust#148530 (update the bootstrap readme) - rust-lang/rust#148608 (Add test for --test-builder success path) - rust-lang/rust#148636 (bootstrap: respect `build.python` on macOS) - rust-lang/rust#148639 (test(rustdoc): move tests into jump-to-def) - rust-lang/rust#148647 (Check unsafety for non-macro attributes in `validate_attr`) - rust-lang/rust#148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.92.0` → `1.93.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.93.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1930-2026-01-22) [Compare Source](rust-lang/rust@1.92.0...1.93.0) \========================== <a id="1.93.0-Language"></a> ## Language - [Stabilize several s390x `vector`-related target features and the `is_s390x_feature_detected!` macro](rust-lang/rust#145656) - [Stabilize declaration of C-style variadic functions for the `system` ABI](rust-lang/rust#145954) - [Emit error when using some keyword as a `cfg` predicate](rust-lang/rust#146978) - [Stabilize `asm_cfg`](rust-lang/rust#147736) - [During const-evaluation, support copying pointers byte-by-byte](rust-lang/rust#148259) - [LUB coercions now correctly handle function item types, and functions with differing safeties](rust-lang/rust#148602) - [Allow `const` items that contain mutable references to `static` (which is *very* unsafe, but not *always* UB)](rust-lang/rust#148746) - [Add warn-by-default `const_item_interior_mutations` lint to warn against calls which mutate interior mutable `const` items](rust-lang/rust#148407) - [Add warn-by-default `function_casts_as_integer` lint](rust-lang/rust#141470) <a id="1.93.0-Compiler"></a> ## Compiler - [Stabilize `-Cjump-tables=bool`](rust-lang/rust#145974). The flag was previously called `-Zno-jump-tables`. <a id="1.93.0-Platform-Support"></a> ## Platform Support - [Promote `riscv64a23-unknown-linux-gnu` to Tier 2 (without host tools)](rust-lang/rust#148435) Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html <a id="1.93.0-Libraries"></a> ## Libraries - [Stop internally using `specialization` on the `Copy` trait as it is unsound in the presence of lifetime dependent `Copy` implementations. This may result in some performance regressions as some standard library APIs may now call `Clone::clone` instead of performing bitwise copies](rust-lang/rust#135634) - [Allow the global allocator to use thread-local storage and `std::thread::current()`](rust-lang/rust#144465) - [Make `BTree::append` not update existing keys when appending an entry which already exists](rust-lang/rust#145628) - [Don't require `T: RefUnwindSafe` for `vec::IntoIter<T>: UnwindSafe`](rust-lang/rust#145665) <a id="1.93.0-Stabilized-APIs"></a> ## Stabilized APIs - [`<[MaybeUninit<T>]>::assume_init_drop`](https://doc.rust-lang.org/stable/core/primitive.slice.html#method.assume_init_drop) - [`<[MaybeUninit<T>]>::assume_init_ref`](https://doc.rust-lang.org/stable/core/primitive.slice.html#method.assume_init_ref) - [`<[MaybeUninit<T>]>::assume_init_mut`](https://doc.rust-lang.org/stable/core/primitive.slice.html#method.assume_init_mut) - [`<[MaybeUninit<T>]>::write_copy_of_slice`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.write_copy_of_slice) - [`<[MaybeUninit<T>]>::write_clone_of_slice`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.write_clone_of_slice) - [`String::into_raw_parts`](https://doc.rust-lang.org/stable/std/string/struct.String.html#method.into_raw_parts) - [`Vec::into_raw_parts`](https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.into_raw_parts) - [`<iN>::unchecked_neg`](https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_neg) - [`<iN>::unchecked_shl`](https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_shl) - [`<iN>::unchecked_shr`](https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_shr) - [`<uN>::unchecked_shl`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.unchecked_shl) - [`<uN>::unchecked_shr`](https://doc.rust-lang.org/stable/std/primitive.usize.html#method.unchecked_shr) - [`<[T]>::as_array`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_array) - [`<[T]>::as_array_mut`](https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_mut_array) - [`<*const [T]>::as_array`](https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.as_array) - [`<*mut [T]>::as_array_mut`](https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.as_mut_array) - [`VecDeque::pop_front_if`](https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.pop_front_if) - [`VecDeque::pop_back_if`](https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.pop_back_if) - [`Duration::from_nanos_u128`](https://doc.rust-lang.org/stable/std/time/struct.Duration.html#method.from_nanos_u128) - [`char::MAX_LEN_UTF8`](https://doc.rust-lang.org/stable/std/primitive.char.html#associatedconstant.MAX_LEN_UTF8) - [`char::MAX_LEN_UTF16`](https://doc.rust-lang.org/stable/std/primitive.char.html#associatedconstant.MAX_LEN_UTF16) - [`std::fmt::from_fn`](https://doc.rust-lang.org/stable/std/fmt/fn.from_fn.html) - [`std::fmt::FromFn`](https://doc.rust-lang.org/stable/std/fmt/struct.FromFn.html) <a id="1.93.0-Cargo"></a> ## Cargo - [Enable CARGO\_CFG\_DEBUG\_ASSERTIONS in build scripts based on profile](rust-lang/cargo#16160) - [In `cargo tree`, support long forms for `--format` variables](rust-lang/cargo#16204) - [Add `--workspace` to `cargo clean`](rust-lang/cargo#16263) <a id="1.93.0-Rustdoc"></a> ## Rustdoc - [Remove `#![doc(document_private_items)]`](rust-lang/rust#146495) - [Include attribute and derive macros in search filters for "macros"](rust-lang/rust#148176) - [Include extern crates in search filters for `import`](rust-lang/rust#148301) - [Validate usage of crate-level doc attributes](rust-lang/rust#149197). This means if any of `html_favicon_url`, `html_logo_url`, `html_playground_url`, `issue_tracker_base_url`, or `html_no_source` either has a missing value, an unexpected value, or a value of the wrong type, rustdoc will emit the deny-by-default lint `rustdoc::invalid_doc_attributes`. <a id="1.93.0-Compatibility-Notes"></a> ## Compatibility Notes - [Introduce `pin_v2` into the builtin attributes namespace](rust-lang/rust#139751) - [Update bundled musl to 1.2.5](rust-lang/rust#142682) - [On Emscripten, the unwinding ABI used when compiling with `panic=unwind` was changed from the JS exception handling ABI to the wasm exception handling ABI.](rust-lang/rust#147224) If linking C/C++ object files with Rust objects, `-fwasm-exceptions` must be passed to the linker now. On nightly Rust, it is possible to get the old behavior with `-Zwasm-emscripten-eh=false -Zbuild-std`, but it will be removed in a future release. - The `#[test]` attribute, used to define tests, was previously ignored in various places where it had no meaning (e.g on trait methods or types). Putting the `#[test]` attribute in these places is no longer ignored, and will now result in an error; this may also result in errors when generating rustdoc. [Error when `test` attribute is applied to structs](rust-lang/rust#147841) - Cargo now sets the `CARGO_CFG_DEBUG_ASSERTIONS` environment variable in more situations. This will cause crates depending on `static-init` versions 1.0.1 to 1.0.3 to fail compilation with "failed to resolve: use of unresolved module or unlinked crate `parking_lot`". See [the linked issue](rust-lang/rust#150646 (comment)) for details. - [User written types in the `offset_of!` macro are now checked to be well formed.](rust-lang/rust#150465) - `cargo publish` no longer emits `.crate` files as a final artifact for user access when the `build.build-dir` config is unset - [Upgrade the `deref_nullptr` lint from warn-by-default to deny-by-default](rust-lang/rust#148122) - [Add future-incompatibility warning for `...` function parameters without a pattern outside of `extern` blocks](rust-lang/rust#143619) - [Introduce future-compatibility warning for `repr(C)` enums whose discriminant values do not fit into a `c_int` or `c_uint`](rust-lang/rust#147017) - [Introduce future-compatibility warning against ignoring `repr(C)` types as part of `repr(transparent)`](rust-lang/rust#147185) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

Pkgsrc changes: * Update version & checksums. * Adapt openssl-src patches to minor version update. Noteable failures at the time of commit: * The cross-build for sparc64 fails, not yet reported. Upstream changes relative to 1.92.0: Version 1.93 (2026-01-22) ========================== Language -------- - [Add warn-by-default `function_casts_as_integer` lint] (rust-lang/rust#141470) - [Add future-incompatibility warning for `...` function parameters without a pattern outside of `extern` blocks] (rust-lang/rust#143619) - [Stabilize several s390x `vector`-related target features and the `is_s390x_feature_detected!` macro] (rust-lang/rust#145656) - [Stabilize declaration of C-style variadic functions for the `system` ABI] (rust-lang/rust#145954) - [Emit error when using some keyword as a `cfg` predicate] (rust-lang/rust#146978) - [Introduce future-compatibility warning for `repr(C)` enums whose discriminant values do not fit into a `c_int` or `c_uint`] (rust-lang/rust#147017) - [Introduce future-compatibility warning against ignoring `repr(C)` types as part of `repr(transparent)`] (rust-lang/rust#147185) - [Stabilize `asm_cfg`] (rust-lang/rust#147736) - [Upgrade the `deref_nullptr` lint from warn-by-default to deny-by-default] (rust-lang/rust#148122) - [During const-evaluation, support copying pointers byte-by-byte] (rust-lang/rust#148259) - [Add warn-by-default `const_item_interior_mutations` lint to warn against calls which mutate interior mutable `const` items] (rust-lang/rust#148407) - [LUB coercions now correctly handle function item types, and functions with differing safeties] (rust-lang/rust#148602) - [Allow `const` items that contain mutable references to `static` (which is *very* unsafe, but not *always* UB)] (rust-lang/rust#148746) Compiler -------- - [Stabilize `-Cjump-tables=bool`] (rust-lang/rust#145974). The flag was previously called `-Zno-jump-tables`. - [Promote `riscv64a23-unknown-linux-gnu` to Tier 2 (without host tools)] (rust-lang/rust#148435) Platform Support ---------------- Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. [platform-support-doc]: https://doc.rust-lang.org/rustc/platform-support.html Libraries --------- - [Stop internally using `specialization` on the `Copy` trait as it is unsound in the presence of lifetime dependent `Copy` implementations. This may result in some performance regressions as some standard library APIs may now call `Clone::clone` instead of performing bitwise copies] (rust-lang/rust#135634) - [Allow the global allocator to use thread-local storage and `std::thread::current()`] (rust-lang/rust#144465) - [Make `BTree::append` not update existing keys when appending an entry which already exists] (rust-lang/rust#145628) - [Don't require `T: RefUnwindSafe` for `vec::IntoIter<T>: UnwindSafe`] (rust-lang/rust#145665) Stabilized APIs --------------- - [`<MaybeUninit<T>>::assume_init_drop`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.assume_init_drop) - [`<MaybeUninit<T>>::assume_init_ref`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.assume_init_ref) - [`<MaybeUninit<T>>::assume_init_mut`] (https://doc.rust-lang.org/stable/core/mem/union.MaybeUninit.html#method.assume_init_mut) - [`<[MaybeUninit<T>]>::write_copy_of_slice`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.write_copy_of_slice) - [`<[MaybeUninit<T>]>::write_clone_of_slice`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.write_clone_of_slice) - [`String::into_raw_parts`] (https://doc.rust-lang.org/stable/std/string/struct.String.html#method.into_raw_parts) - [`Vec::into_raw_parts`] (https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.into_raw_parts) - [`<iN>::unchecked_neg`] (https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_neg) - [`<iN>::unchecked_shl`] (https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_shl) - [`<iN>::unchecked_shr`] (https://doc.rust-lang.org/stable/std/primitive.isize.html#method.unchecked_shr) - [`<uN>::unchecked_shl`] (https://doc.rust-lang.org/stable/std/primitive.usize.html#method.unchecked_shl) - [`<uN>::unchecked_shr`] (https://doc.rust-lang.org/stable/std/primitive.usize.html#method.unchecked_shr) - [`<[T]>::as_array`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_array) - [`<[T]>::as_array_mut`] (https://doc.rust-lang.org/stable/std/primitive.slice.html#method.as_mut_array) - [`<*const [T]>::as_array`] (https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.as_array) - [`<*mut [T]>::as_array_mut`] (https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.as_mut_array) - [`VecDeque::pop_front_if`] (https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.pop_front_if) - [`VecDeque::pop_back_if`] (https://doc.rust-lang.org/stable/std/collections/struct.VecDeque.html#method.pop_back_if) - [`Duration::from_nanos_u128`] (https://doc.rust-lang.org/stable/std/time/struct.Duration.html#method.from_nanos_u128) - [`char::MAX_LEN_UTF8`] (https://doc.rust-lang.org/stable/std/primitive.char.html#associatedconstant.MAX_LEN_UTF8) - [`char::MAX_LEN_UTF16`] (https://doc.rust-lang.org/stable/std/primitive.char.html#associatedconstant.MAX_LEN_UTF16) - [`std::fmt::from_fn`] (https://doc.rust-lang.org/stable/std/fmt/fn.from_fn.html) - [`std::fmt::FromFn`] (https://doc.rust-lang.org/stable/std/fmt/struct.FromFn.html) Cargo ----- - [Enable CARGO_CFG_DEBUG_ASSERTIONS in build scripts based on profile] (rust-lang/cargo#16160) - [In `cargo tree`, support long forms for `--format` variables] (rust-lang/cargo#16204) - [Add `--workspace` to `cargo clean`] (rust-lang/cargo#16263) Rustdoc ----- - [Remove `#![doc(document_private_items)]`](rust-lang/rust#146495) - [Include attribute and derive macros in search filters for "macros"](rust-lang/rust#148176) - [Include extern crates in search filters for `import`](rust-lang/rust#148301) - [Validate usage of crate-level doc attributes](rust-lang/rust#149197). This means if any of `html_favicon_url`, `html_logo_url`, `html_playground_url`, `issue_tracker_base_url`, or `html_no_source` either has a missing value, an unexpected value, or a value of the wrong type, rustdoc will emit the deny-by-default lint `rustdoc::invalid_doc_attributes`. Compatibility Notes ------------------- - [Introduce `pin_v2` into the builtin attributes namespace] (rust-lang/rust#139751) - [Update bundled musl to 1.2.5] (rust-lang/rust#142682) - [On Emscripten, the unwinding ABI used when compiling with `panic=unwind` was changed from the JS exception handling ABI to the wasm exception handling ABI.] (rust-lang/rust#147224) If linking C/C++ object files with Rust objects, `-fwasm-exceptions` must be passed to the linker now. On nightly Rust, it is possible to get the old behavior with `-Zwasm-emscripten-eh=false -Zbuild-std`, but it will be removed in a future release. - The `#[test]` attribute, used to define tests, was previously ignored in various places where it had no meaning (e.g on trait methods or types). Putting the `#[test]` attribute in these places is no longer ignored, and will now result in an error; this may also result in errors when generating rustdoc. [Error when `test` attribute is applied to structs] (rust-lang/rust#147841) - Cargo now sets the `CARGO_CFG_DEBUG_ASSERTIONS` environment variable in more situations. This will cause crates depending on `static-init` versions 1.0.1 to 1.0.3 to fail compilation with "failed to resolve: use of unresolved module or unlinked crate `parking_lot`". See [the linked issue] (rust-lang/rust#150646 (comment)) for details. - [User written types in the `offset_of!` macro are now checked to be well formed.] (rust-lang/rust#150465) - `cargo publish` no longer emits `.crate` files as a final artifact for user access when the `build.build-dir` config is unset

rustbot assigned joshtriplett Jul 7, 2025

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 Jul 7, 2025

beetrees force-pushed the varargs-named branch from 5831c91 to ebeaa0e Compare July 7, 2025 23:15

This comment has been minimized.

Sign in to view

beetrees force-pushed the varargs-named branch from ebeaa0e to e18dc17 Compare July 8, 2025 01:36

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 14, 2025

craterbot removed the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Jul 19, 2025

folkertdev force-pushed the varargs-named branch from e32cb1e to 6e28ba9 Compare November 10, 2025 10:09

This comment has been minimized.

Sign in to view

c_variadic: Add future-incompatibility warning for ... arguments …

02e1f44

…without a pattern outside of `extern` blocks

folkertdev force-pushed the varargs-named branch from 6e28ba9 to 02e1f44 Compare November 10, 2025 13:34

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 Nov 10, 2025

Zalathar mentioned this pull request Nov 11, 2025

Rollup of 17 pull requests #148810

Closed

Zalathar mentioned this pull request Nov 11, 2025

Rollup of 16 pull requests #148813

Closed

Zalathar mentioned this pull request Nov 11, 2025

Rollup of 15 pull requests #148817

Merged

bors merged commit 3538bc1 into rust-lang:main Nov 11, 2025
11 of 12 checks passed

rustbot added this to the 1.93.0 milestone Nov 11, 2025

folkertdev mentioned this pull request Dec 4, 2025

Tracking issue for RFC 2137: Support defining C-compatible variadic functions in Rust (c_variadic) #44930

Open

3 tasks

BoxyUwU mentioned this pull request Jan 7, 2026

Draft release notes for 1.93 #150760

Closed

Uh oh!

c_variadic: Add future-incompatibility warning for ... arguments without a pattern outside of extern blocks #143619

c_variadic: Add future-incompatibility warning for ... arguments without a pattern outside of extern blocks #143619

Conversation

beetrees commented Jul 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jul 7, 2025

Uh oh!

This comment has been minimized.

rustbot commented Jul 8, 2025

Uh oh!

compiler-errors commented Jul 8, 2025

Uh oh!

rust-bors bot commented Jul 8, 2025

Uh oh!

beetrees commented Jul 8, 2025

Uh oh!

compiler-errors commented Jul 8, 2025

Uh oh!

rust-bors bot commented Jul 8, 2025

Uh oh!

rust-bors bot commented Jul 8, 2025

Uh oh!

folkertdev commented Jul 13, 2025

Uh oh!

beetrees commented Jul 14, 2025

Uh oh!

compiler-errors commented Jul 14, 2025

Uh oh!

craterbot commented Jul 14, 2025

Uh oh!

craterbot commented Jul 17, 2025

Uh oh!

craterbot commented Jul 18, 2025

Uh oh!

folkertdev commented Jul 19, 2025

Uh oh!

craterbot commented Jul 19, 2025

Uh oh!

craterbot commented Jul 19, 2025

Uh oh!

folkertdev commented Jul 19, 2025

Uh oh!

craterbot commented Jul 19, 2025

Uh oh!

craterbot commented Jul 19, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

rustbot commented Nov 10, 2025

Uh oh!

folkertdev commented Nov 10, 2025

Uh oh!

bors commented Nov 10, 2025

Uh oh!

bors commented Nov 11, 2025

Uh oh!

Zalathar commented Nov 11, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks #143619

`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks #143619

beetrees commented Jul 7, 2025 •

edited

Loading