Rollup of 8 pull requests #147440
Open
Rollup of 8 pull requests #147440
+594
−258
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
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
Previously, `x test collect-license-metadata` gave the following message
on errors:
```
gathering license information from REUSE (this might take a minute...)
finished gathering the license information from REUSE in 78.69s
loading existing license information
The existing /home/runner/work/ferrocene/ferrocene/license-metadata.json
file is out of date.
Run ./x run collect-license-metadata to update it.
Error: The existing
/home/runner/work/ferrocene/ferrocene/license-metadata.json file doesn't
match what REUSE reports.
Bootstrap failed while executing `test collect-license-metadata`
```
Notable, this doesn't actually say what went wrong.
Print a diff in addition so it's more clear what broke:
```
...
"license": {
"copyright": [
+ "2010 The Rust Project Developers",
"2016, 2017, 2018, 2019, 2020, 2021 AXE Consultants. All Rights",
+ "License. Subject to the terms and conditions of this",
"Notice",
- "The Ferrocene Developers"
+ "The Ferrocene Developers",
+ "[yyyy] [name of copyright owner]"
],
...
```
Currently, this prints the entire text of the JSON file as context.
That's not ideal, but it's rare for this to fail, so I think it's ok for
now.
I considered using `assert_json_diff` instead of `similar`, but its
errors are a lot harder to read IMO, even though they are better at
omitting unnecessary context:
```
Diff: json atoms at path ".files.children[0].children[10].license.copyright[0]" are not equal:
lhs:
"2016 The Fuchsia Authors"
rhs:
"2019 The Crossbeam Project Developers"
json atoms at path ".files.children[0].children[10].license.spdx" are not equal:
lhs:
"BSD-2-Clause AND (Apache-2.0 OR MIT)"
rhs:
"Apache-2.0 OR MIT"
json atom at path ".files.children[0].children[10].children" is missing from lhs
json atoms at path ".files.children[0].children[10].name" are not equal:
lhs:
"library/std/src/sys/sync/mutex/fuchsia.rs"
rhs:
"library/std/src/sync/mpmc"
...
```
Few tests are larger than a handful of kilobytes, and nowadays we scan the whole file for directives anyway, so there's little reason not to just read the whole thing up-front. This avoids having to deal with I/O within `iter_directives`, which should make it easier to overhaul directive processing.
Prevent downstream `impl DerefMut for Pin<LocalType>` The safety requirements for [`PinCoerceUnsized`](https://doc.rust-lang.org/stable/std/pin/trait.PinCoerceUnsized.html) are essentially that the type does not have a malicious `Deref` or `DerefMut` impl. However, the `Pin` type is fundamental, so the end-user can provide their own implementation of `DerefMut` for `Pin<&SomeLocalType>`, so it's possible for `Pin` to have a malicious `DerefMut` impl. This unsoundness is known as rust-lang#85099. Unfortunately, this means that the implementation of `PinCoerceUnsized` for `Pin` is currently unsound. To fix that, modify the impl so that it becomes impossible for downstream crates to provide their own implementation of `DerefMut` for `Pin` by abusing a hidden struct that is not fundamental. This PR is a breaking change, but it fixes rust-lang#85099. The PR supersedes rust-lang#144896. r? lcnr
…patible, r=rcvalle kcfi: only reify trait methods when dyn-compatible fixes rust-lang#146853 Only generate a `ReifyShim` for trait method calls if the trait is dyn-compatible. Until now kcfi would generate a `ReifyShim` whenever a trait method was cast to a function pointer. But technically the shim is only needed for dyn-compatible traits (where the method might end up in a vtable). Up to this point that was only slightly inefficient, but in combination with c-variadic trait methods it is wrong. For c-variadic trait methods the generated shim is incorrect, and that is why c-variadic methods make a trait no longer dyn-compatible: we should simply never generate a `ReifyShim` that is c-variadic. With this change the documentation on `ReifyReason` is now actually correct: > If KCFI is enabled, creating a function pointer from a method on a dyn-compatible trait. This includes the case of converting `::call`-like methods on closure-likes to function pointers. cc ``@maurer`` ``@workingjubilee`` r? ``@rcvalle``
Add a new `wasm32-wasip3` target to Rust This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group. As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a more-ready-than-nonexistent state by the time this happens in December. For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably: * The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup. * Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use. * Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target. These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change. [`wasip3` crate]: https://crates.io/crates/wasip3
Use globals instead of metadata for std::autodiff LLVM's Metadata is quite fragile. In debug builds we use incremental compilation, which caused the metadata to be dropped. With this change we use named globals instead of metadata to instruct Enzyme how to differentiate functions. Globals are proper llvm values and thus can't be dropped. Also added an incremental/dbg test which now passes, to unblock the EnzymeAD CI which wants to run Rust autodiff tests. r? compiler
…inference-error, r=chenyukang Fix; correct placement of type inference error for method calls Addresses a FIXME for displaying errors on method calls; Before; ``` error[E0282]: type annotations needed --> /<location>/src/main.rs:48:15 | ## | e.is_conversion_error(); | ^^^^^^^^^^^^^^^^^^^ cannot infer type ``` After; ``` error[E0282]: type annotations needed --> /<location>/src/main.rs:48:15 | ## | e.is_conversion_error(); | ^ cannot infer type ```
collect-license-metadata: Print a diff of the expected output
Previously, `x test collect-license-metadata` gave the following message on errors:
```
gathering license information from REUSE (this might take a minute...)
finished gathering the license information from REUSE in 78.69s
loading existing license information
The existing /home/runner/work/ferrocene/ferrocene/license-metadata.json
file is out of date.
Run ./x run collect-license-metadata to update it.
Error: The existing
/home/runner/work/ferrocene/ferrocene/license-metadata.json file doesn't
match what REUSE reports.
Bootstrap failed while executing `test collect-license-metadata`
```
Notable, this doesn't actually say what went wrong. Print a diff in addition so it's more clear what broke:
```
...
"license": {
"copyright": [
+ "2010 The Rust Project Developers",
"2016, 2017, 2018, 2019, 2020, 2021 AXE Consultants. All Rights",
+ "License. Subject to the terms and conditions of this",
"Notice",
- "The Ferrocene Developers"
+ "The Ferrocene Developers",
+ "[yyyy] [name of copyright owner]"
],
...
```
Currently, this prints the entire text of the JSON file as context. That's not ideal, but it's rare for this to fail, so I think it's ok for now.
I considered using `assert_json_diff` instead of `similar`, but its errors are a lot harder to read IMO, even though they are better at omitting unnecessary context:
```
Diff: json atoms at path ".files.children[0].children[10].license.copyright[0]" are not equal:
lhs:
"2016 The Fuchsia Authors"
rhs:
"2019 The Crossbeam Project Developers"
json atoms at path ".files.children[0].children[10].license.spdx" are not equal:
lhs:
"BSD-2-Clause AND (Apache-2.0 OR MIT)"
rhs:
"Apache-2.0 OR MIT"
json atom at path ".files.children[0].children[10].children" is missing from lhs
json atoms at path ".files.children[0].children[10].name" are not equal:
lhs:
"library/std/src/sys/sync/mutex/fuchsia.rs"
rhs:
"library/std/src/sync/mpmc"
...
```
compiletest: Read the whole test file before parsing directives Few tests are larger than a handful of kilobytes, and nowadays we scan the whole file for directives anyway, so there's little reason not to just read the whole thing up-front. This avoids having to deal with I/O within `iter_directives`, which should make it easier to overhaul directive processing. r? jieyouxu
…henyukang Fix doc comment
rustbot
added
A-compiletest
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Oct 7, 2025
Rollup of 8 pull requests Successful merges: - #145608 (Prevent downstream `impl DerefMut for Pin<LocalType>`) - #146865 (kcfi: only reify trait methods when dyn-compatible) - #147205 (Add a new `wasm32-wasip3` target to Rust) - #147390 (Use globals instead of metadata for std::autodiff) - #147398 (Fix; correct placement of type inference error for method calls) - #147422 (collect-license-metadata: Print a diff of the expected output) - #147431 (compiletest: Read the whole test file before parsing directives) - #147433 (Fix doc comment) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
Killed. Spurious. @bors retry |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Oct 7, 2025
Rollup of 8 pull requests Successful merges: - #145608 (Prevent downstream `impl DerefMut for Pin<LocalType>`) - #146865 (kcfi: only reify trait methods when dyn-compatible) - #147205 (Add a new `wasm32-wasip3` target to Rust) - #147390 (Use globals instead of metadata for std::autodiff) - #147398 (Fix; correct placement of type inference error for method calls) - #147422 (collect-license-metadata: Print a diff of the expected output) - #147431 (compiletest: Read the whole test file before parsing directives) - #147433 (Fix doc comment) r? `@ghost` `@rustbot` modify labels: rollup
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Successful merges:
impl DerefMut for Pin<LocalType>#145608 (Prevent downstreamimpl DerefMut for Pin<LocalType>)wasm32-wasip3target to Rust #147205 (Add a newwasm32-wasip3target to Rust)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup