stabilize extern_system_varargs #145954
Merged
stabilize extern_system_varargs #145954
+4
−27
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Collaborator
|
HIR ty lowering was modified cc @fmease |
169a301 to
3e03e56
Compare
This comment has been minimized.
This comment has been minimized.
3e03e56 to
09dd913
Compare
This comment has been minimized.
This comment has been minimized.
09dd913 to
0946e8b
Compare
fmease
added a commit
to fmease/rust
that referenced
this pull request
Sep 1, 2025
…kingjubilee stabilize c-style varargs for sysv64, win64, efiapi, aapcs This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to rust-lang#145954. **Previous (combined) PR description:** This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates. The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](rust-lang#136946 (comment)) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR): - "stdcall" for win32 targets **for non-variadic functions** - "C" for everything else This had been previously stabilized *without FCP* in rust-lang#116161, which got reverted in rust-lang#136897. There was also a "fun" race condition involved with the system ABI being [added](rust-lang#119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang#116161. There was a question raised [here](rust-lang#116161 (comment)) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me. Fixes rust-lang#100189 Cc `@rust-lang/lang` # Stabilization report > ## General design > ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? AFAIK there is no RFC. The tracking issues are - rust-lang#100189 - rust-lang#136946 > ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The only controversial point is whether "system" ABI functions should support variadics. - Pro: This allows crates like windows-rs to consistently use "system", see e.g. microsoft/windows-rs#3626. - Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](rust-lang#136946 (comment)). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those. Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do ```rust extern "system" { // put all the things here } ``` and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there). (I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.) > ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](rust-lang#44930). > ## Has a Call for Testing period been conducted? If so, what feedback was received? > > Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results". There was no call for testing. A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics. > ## Implementation quality All rustc does here is forward the ABI to LLVM so there's lot a lot to say here... > ### Summarize the major parts of the implementation and provide links into the code (or to PRs) > > An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>. The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126). The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85). > ### Summarize existing test coverage of this feature > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time. > > - What does the test coverage landscape for this feature look like? > - Tests for compiler errors when you use the feature wrongly or make mistakes? > - Tests for the feature itself: > - Limits of the feature (so failing compilation) > - Exercises of edge cases of the feature > - Tests that checks the feature works as expected (where applicable, `//@ run-pass`). > - Are there any intentional gaps in test coverage? > > Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.). Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64: - rust-lang#144359 - rust-lang#144379 We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.) The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`. > ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? None that I am aware of. > ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None that I am aware of. > ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization `@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature. > ### Which tools need to be adjusted to support this feature. Has this work been done? > > Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs. Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here. > ## Type system and execution rules > ### What compilation-time checks are done that are needed to prevent undefined behavior? > > (Be sure to link to tests demonstrating that these tests are being done.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### What updates are needed to the reference/specification? (link to PRs when they exist) - rust-lang/reference#1936 > ## Common interactions > ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. > ### What other unstable features may be exposed by this feature? None.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Sep 2, 2025
…kingjubilee stabilize c-style varargs for sysv64, win64, efiapi, aapcs This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to rust-lang#145954. **Previous (combined) PR description:** This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates. The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](rust-lang#136946 (comment)) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR): - "stdcall" for win32 targets **for non-variadic functions** - "C" for everything else This had been previously stabilized *without FCP* in rust-lang#116161, which got reverted in rust-lang#136897. There was also a "fun" race condition involved with the system ABI being [added](rust-lang#119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang#116161. There was a question raised [here](rust-lang#116161 (comment)) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me. Fixes rust-lang#100189 Cc `@rust-lang/lang` # Stabilization report > ## General design > ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? AFAIK there is no RFC. The tracking issues are - rust-lang#100189 - rust-lang#136946 > ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The only controversial point is whether "system" ABI functions should support variadics. - Pro: This allows crates like windows-rs to consistently use "system", see e.g. microsoft/windows-rs#3626. - Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](rust-lang#136946 (comment)). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those. Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do ```rust extern "system" { // put all the things here } ``` and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there). (I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.) > ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](rust-lang#44930). > ## Has a Call for Testing period been conducted? If so, what feedback was received? > > Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results". There was no call for testing. A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics. > ## Implementation quality All rustc does here is forward the ABI to LLVM so there's lot a lot to say here... > ### Summarize the major parts of the implementation and provide links into the code (or to PRs) > > An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>. The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126). The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85). > ### Summarize existing test coverage of this feature > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time. > > - What does the test coverage landscape for this feature look like? > - Tests for compiler errors when you use the feature wrongly or make mistakes? > - Tests for the feature itself: > - Limits of the feature (so failing compilation) > - Exercises of edge cases of the feature > - Tests that checks the feature works as expected (where applicable, `//@ run-pass`). > - Are there any intentional gaps in test coverage? > > Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.). Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64: - rust-lang#144359 - rust-lang#144379 We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.) The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`. > ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? None that I am aware of. > ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None that I am aware of. > ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization `@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature. > ### Which tools need to be adjusted to support this feature. Has this work been done? > > Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs. Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here. > ## Type system and execution rules > ### What compilation-time checks are done that are needed to prevent undefined behavior? > > (Be sure to link to tests demonstrating that these tests are being done.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### What updates are needed to the reference/specification? (link to PRs when they exist) - rust-lang/reference#1936 > ## Common interactions > ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. > ### What other unstable features may be exposed by this feature? None.
rust-timer
added a commit
that referenced
this pull request
Sep 2, 2025
Rollup merge of #144066 - RalfJung:extern-c-variadics, r=workingjubilee stabilize c-style varargs for sysv64, win64, efiapi, aapcs This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to #145954. **Previous (combined) PR description:** This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates. The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](#136946 (comment)) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR): - "stdcall" for win32 targets **for non-variadic functions** - "C" for everything else This had been previously stabilized *without FCP* in #116161, which got reverted in #136897. There was also a "fun" race condition involved with the system ABI being [added](#119587) to the list of variadic-supporting ABIs between the creation and merge of #116161. There was a question raised [here](#116161 (comment)) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me. Fixes #100189 Cc `@rust-lang/lang` # Stabilization report > ## General design > ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? AFAIK there is no RFC. The tracking issues are - #100189 - #136946 > ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The only controversial point is whether "system" ABI functions should support variadics. - Pro: This allows crates like windows-rs to consistently use "system", see e.g. microsoft/windows-rs#3626. - Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](#136946 (comment)). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those. Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do ```rust extern "system" { // put all the things here } ``` and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there). (I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.) > ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](#44930). > ## Has a Call for Testing period been conducted? If so, what feedback was received? > > Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results". There was no call for testing. A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics. > ## Implementation quality All rustc does here is forward the ABI to LLVM so there's lot a lot to say here... > ### Summarize the major parts of the implementation and provide links into the code (or to PRs) > > An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>. The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126). The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85). > ### Summarize existing test coverage of this feature > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time. > > - What does the test coverage landscape for this feature look like? > - Tests for compiler errors when you use the feature wrongly or make mistakes? > - Tests for the feature itself: > - Limits of the feature (so failing compilation) > - Exercises of edge cases of the feature > - Tests that checks the feature works as expected (where applicable, `//@ run-pass`). > - Are there any intentional gaps in test coverage? > > Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.). Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64: - #144359 - #144379 We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.) The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`. > ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? None that I am aware of. > ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None that I am aware of. > ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization `@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature. > ### Which tools need to be adjusted to support this feature. Has this work been done? > > Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs. Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here. > ## Type system and execution rules > ### What compilation-time checks are done that are needed to prevent undefined behavior? > > (Be sure to link to tests demonstrating that these tests are being done.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### What updates are needed to the reference/specification? (link to PRs when they exist) - rust-lang/reference#1936 > ## Common interactions > ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. > ### What other unstable features may be exposed by this feature? None.
0946e8b to
b2b4397
Compare
This comment has been minimized.
This comment has been minimized.
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Sep 3, 2025
stabilize c-style varargs for sysv64, win64, efiapi, aapcs This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to rust-lang/rust#145954. **Previous (combined) PR description:** This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates. The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](rust-lang/rust#136946 (comment)) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR): - "stdcall" for win32 targets **for non-variadic functions** - "C" for everything else This had been previously stabilized *without FCP* in rust-lang/rust#116161, which got reverted in rust-lang/rust#136897. There was also a "fun" race condition involved with the system ABI being [added](rust-lang/rust#119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang/rust#116161. There was a question raised [here](rust-lang/rust#116161 (comment)) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me. Fixes rust-lang/rust#100189 Cc `@rust-lang/lang` # Stabilization report > ## General design > ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? AFAIK there is no RFC. The tracking issues are - rust-lang/rust#100189 - rust-lang/rust#136946 > ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The only controversial point is whether "system" ABI functions should support variadics. - Pro: This allows crates like windows-rs to consistently use "system", see e.g. microsoft/windows-rs#3626. - Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](rust-lang/rust#136946 (comment)). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those. Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do ```rust extern "system" { // put all the things here } ``` and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there). (I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.) > ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](rust-lang/rust#44930). > ## Has a Call for Testing period been conducted? If so, what feedback was received? > > Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results". There was no call for testing. A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics. > ## Implementation quality All rustc does here is forward the ABI to LLVM so there's lot a lot to say here... > ### Summarize the major parts of the implementation and provide links into the code (or to PRs) > > An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>. The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126). The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85). > ### Summarize existing test coverage of this feature > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time. > > - What does the test coverage landscape for this feature look like? > - Tests for compiler errors when you use the feature wrongly or make mistakes? > - Tests for the feature itself: > - Limits of the feature (so failing compilation) > - Exercises of edge cases of the feature > - Tests that checks the feature works as expected (where applicable, `//@ run-pass`). > - Are there any intentional gaps in test coverage? > > Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.). Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64: - rust-lang/rust#144359 - rust-lang/rust#144379 We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.) The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`. > ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? None that I am aware of. > ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None that I am aware of. > ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization `@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature. > ### Which tools need to be adjusted to support this feature. Has this work been done? > > Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs. Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here. > ## Type system and execution rules > ### What compilation-time checks are done that are needed to prevent undefined behavior? > > (Be sure to link to tests demonstrating that these tests are being done.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### What updates are needed to the reference/specification? (link to PRs when they exist) - rust-lang/reference#1936 > ## Common interactions > ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. > ### What other unstable features may be exposed by this feature? None.
Member
|
So, uh, waiting on @workingjubilee to weigh in? What's the status here? |
github-actions bot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Sep 9, 2025
…kingjubilee stabilize c-style varargs for sysv64, win64, efiapi, aapcs This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to rust-lang#145954. **Previous (combined) PR description:** This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates. The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](rust-lang#136946 (comment)) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR): - "stdcall" for win32 targets **for non-variadic functions** - "C" for everything else This had been previously stabilized *without FCP* in rust-lang#116161, which got reverted in rust-lang#136897. There was also a "fun" race condition involved with the system ABI being [added](rust-lang#119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang#116161. There was a question raised [here](rust-lang#116161 (comment)) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me. Fixes rust-lang#100189 Cc `@rust-lang/lang` # Stabilization report > ## General design > ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? AFAIK there is no RFC. The tracking issues are - rust-lang#100189 - rust-lang#136946 > ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. The only controversial point is whether "system" ABI functions should support variadics. - Pro: This allows crates like windows-rs to consistently use "system", see e.g. microsoft/windows-rs#3626. - Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](rust-lang#136946 (comment)). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those. Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do ```rust extern "system" { // put all the things here } ``` and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there). (I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.) > ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](rust-lang#44930). > ## Has a Call for Testing period been conducted? If so, what feedback was received? > > Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results". There was no call for testing. A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics. > ## Implementation quality All rustc does here is forward the ABI to LLVM so there's lot a lot to say here... > ### Summarize the major parts of the implementation and provide links into the code (or to PRs) > > An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>. The check for allowed variadic ABIs is [here](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126). The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/compiler/rustc_target/src/spec/abi_map.rs#L82-L85). > ### Summarize existing test coverage of this feature > > Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. > > Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time. > > - What does the test coverage landscape for this feature look like? > - Tests for compiler errors when you use the feature wrongly or make mistakes? > - Tests for the feature itself: > - Limits of the feature (so failing compilation) > - Exercises of edge cases of the feature > - Tests that checks the feature works as expected (where applicable, `//@ run-pass`). > - Are there any intentional gaps in test coverage? > > Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.). Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64: - rust-lang#144359 - rust-lang#144379 We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.) The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`. > ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? None that I am aware of. > ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None that I am aware of. > ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization `@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature. > ### Which tools need to be adjusted to support this feature. Has this work been done? > > Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs. Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here. > ## Type system and execution rules > ### What compilation-time checks are done that are needed to prevent undefined behavior? > > (Be sure to link to tests demonstrating that these tests are being done.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale? Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.) Nothing new here, this just expands the existing support for calling variadic functions to more ABIs. > ### What updates are needed to the reference/specification? (link to PRs when they exist) - rust-lang/reference#1936 > ## Common interactions > ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries? No. > ### What other unstable features may be exposed by this feature? None.
Member
Author
|
@workingjubilee how do you suggest we proceed here? I'd rather not delay this indefinitely... |
Member
|
So, I don't want to delay this longer this is should be, but I also don't have the full context here on whether this should be merged. From a reviewer perspective this is fairly simple and r=me on that. But, I'm not sure if this is going to need another lang FCP? Or at least lang signoff? |
Member
|
Going to nominate for lang. From I can tell from the background here, @workingjubilee had questions about testing: #144066 (comment) Is this PR covered under the FCP in #144066? It doesn't seem at all like the lang team waited for a "resolution" to the concerns raised by jubilee, so I'm curious on current thoughts. |
Collaborator
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Member
Author
b2b4397 to
87024bd
Compare
Collaborator
|
This PR was rebased onto a different master 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. |
Contributor
|
cc @rust-lang/fls |
Member
Author
|
Based on this earlier comment |
Collaborator
rust-timer
added a commit
that referenced
this pull request
Nov 16, 2025
Rollup merge of #145954 - RalfJung:syscall-c-variadics, r=jackh726 stabilize extern_system_varargs Based on top of #144066. This has been already FCP'd over there, but `@workingjubilee` has some concerns regarding "system" varargs specifically (IIUC). Reference PR: rust-lang/reference#2069.
Collaborator
github-actions bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Nov 17, 2025
Rollup of 3 pull requests Successful merges: - rust-lang/rust#145954 (stabilize extern_system_varargs) - rust-lang/rust#148962 (fix(span): track unnormalized source len for dep-info) - rust-lang/rust#148969 (compiletest: Don't apply "emscripten" directives to `wasm32-unknown-unknown`) r? `@ghost` `@rustbot` modify labels: rollup
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Nov 17, 2025
Rollup of 3 pull requests Successful merges: - rust-lang/rust#145954 (stabilize extern_system_varargs) - rust-lang/rust#148962 (fix(span): track unnormalized source len for dep-info) - rust-lang/rust#148969 (compiletest: Don't apply "emscripten" directives to `wasm32-unknown-unknown`) r? `@ghost` `@rustbot` modify labels: rollup
tmeijn
pushed a commit
to tmeijn/dotfiles
that referenced
this pull request
Jan 23, 2026
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. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0Mi44OC4yIiwidXBkYXRlZEluVmVyIjoiNDIuODguMiIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOlsiUmVub3ZhdGUgQm90IiwiYXV0b21hdGlvbjpib3QtYXV0aG9yZWQiLCJkZXBlbmRlbmN5LXR5cGU6Om1pbm9yIl19-->
wip-sync
pushed a commit
to NetBSD/pkgsrc-wip
that referenced
this pull request
Jan 24, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on top of #144066. This has been already FCP'd over there, but @workingjubilee has some concerns regarding "system" varargs specifically (IIUC).
Reference PR: rust-lang/reference#2069.