This commit is the start of an effort to support WASIp2 natively in the
standard library. Before this commit the `wasm32-wasip2` target behaved
exactly like `wasm32-wasip1` target by importing APIs from the core wasm
module `wasi_snapshot_preview1`. These APIs are satisfied by the
`wasm-component-ld` target by using an [adapter] which implements WASIp1
in terms of WASIp2. This adapter comes at a cost, however, in terms of
runtime indirection and instantiation cost, so ideally the adapter would
be removed entirely. The purpose of this adapter was to provide a
smoother on-ramp from WASIp1 to WASIp2 when it was originally created.
The `wasm32-wasip2` target has been around for long enough now that it's
much more established. Additionally the only thing historically blocking
using WASIp2 directly was implementation effort. Work is now underway to
migrate wasi-libc itself to using WASIp2 directly and now seems as good
a time as any to migrate the Rust standard library too.
Implementation-wise the milestones here are:
* The `wasm32-wasip2` target now also depends on the `wasi` crate at
version 0.14.* in addition to the preexisting dependency of 0.11.*.
The 0.14.* release series binds WASIp2 APIs instead of WASIp1 APIs.
* Some preexisting naming around `mod wasi` or `wasi.rs` was renamed to
`wasip1` where appropriate. For example `std::sys::pal::wasi` is now
called `std::sys::pal::wasip1`.
* More platform-specific WASI modules are now split between WASIp1 and
WASIp2. For example getting the current time, randomness, and
process arguments now use WASIp2 APIs directly instead of using WASIp1
APIs that require an adapter.
It's worth pointing out that this PR does not migrate the entire
standard library away from using WASIp1 APIs on the `wasm32-wasip2`
target. Everything related to file descriptors and filesystem APIs is
still using WASIp1. Migrating that is left for a future PR. In the
meantime the goal of this change is to lay the groundwork necessary for
migrating in the future. Eventually the goal is to drop the `wasi`
0.11.* dependency on the `wasm32-wasip2` target (the `wasm32-wasip1`
target will continue to retain this dependency).
[adapter]: https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-preview1-component-adapter/README.md
For `wasm32-wasip2`-and-beyond this tool is required, so in case it's
disabled in `config.toml` add a sanity-check that it's present in the
environment.
When determining if a trait has no entries for the purposes of omitting vptrs from subtrait vtables, consider its transitive supertraits' entries, instead of just its own entries.
When determining if a non-first supertrait vptr can be omitted from a subtrait vtable, check if the supertrait or any of its (transitive) supertraits have methods, instead of only checking if the supertrait itself has methods.
This fixes the soundness issue where a vptr would be omitted for a supertrait with no methods but that itself had a supertrait with methods, while still optimizing the case where the supertrait is "truly" empty (it has no own vtable entries, and none of its (transitive) supertraits have any own vtable entries).
Fixes <https://github.com/rust-lang/rust/issues/145752>
-----
Old description:
~~Treat all non-auto traits as non-empty (possibly having methods) for purposes of determining if we need to emit a vptr for a non-direct supertrait (and for new "sibling" entries after a direct or non-direct supertrait).~~
This fixes (I believe) the soundness issue, ~~but regresses vtable sizes and possibly upcasting perf in some cases when using trait hierarchies with empty non-auto traits (see `tests/ui/traits/vtable/multiple-markers.stderr`) since we use vptrs in some cases where we could re-use the vtable.~~
Fixes <https://github.com/rust-lang/rust/issues/145752>
Re-opens (not anymore) <https://github.com/rust-lang/rust/issues/114942>
Should not affect <https://github.com/rust-lang/rust/issues/131813> (i.e. the soundness issue is still fixed, ~~though the relevant vtables in the `trait Evil` example will be larger now~~)
cc implementation history <https://github.com/rust-lang/rust/pull/131864> <https://github.com/rust-lang/rust/pull/113856>
-----
~~It should be possible to check if a trait has any methods from itself *or* supertraits (instead of just from itself), but to fix the immediate soundness issue, just assume any non-auto trait could have methods. A more optimistic check can be implemented later (or if someone does it soon it could just supercede this PR 😄).~~ Done in latest push
`@rustbot` label A-dyn-trait F-trait_upcasting
`const`ify (the unstable) `str::as_str`
Tracking issue: rust-lang/rust#130366
The method was not initially marked `const` presumably because it is only useful with `Deref`. But now that const traits seem to be a thing that can actually become real, why not make it `const`?
PR `const`ifying `Deref`: rust-lang/rust#145279
Rename `Location::file_with_nul` to `file_as_c_str`
This renames the method to be consistent with the ongoing T-libs-api FCP found at https://github.com/rust-lang/rust/issues/141727#issuecomment-3228016708.
I did not rename the unstable feature as we are going to be stabilizing it soon anyway. This will probably break RfL, so it will require an updated commit hash for the Linux Kernel that I will add here soon.
r? `@Amanieu`
compiletest: Remove several remnants of the old libtest-based executor
I noticed a few bits of low-hanging cleanup that are possible now that the non-libtest executor is well and truly established.
No source fixes
This PR started as a fix for a rendering bug that [got noticed in #143661](https://github.com/rust-lang/rust/pull/143661#discussion_r2199109530), but turned into a fix for any rendering bugs related to files with no source.
- Don't add an end column separator after a file with no source
- Add column separator before secondary messages with no source
- Render continuation between no source labels
Before
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
╰╴
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
╰ note: private field
│
╰ note: private field
```
After
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╰╴
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
├ note: private field
│
╰ note: private field
```
Note: This PR also makes it so `rustc` and `annotate-snippets` match in these cases
Remove unnecessary `[dependencies.unicode-properties]` entries.
The Cargo style guide says to put dependencies on a single line if they fit.
r? `@jdonszelmann`
Fix STD build failing for target_os = "espidf"
A regression from rust-lang/rust#142938
cc `@lolbinarycat`
cc `@ibraheemdev`
ESP-IDF (and a few other embedded Tier-3 systems) is considered `cfg(unix)`, but it does not have the `O_NOFOLLOW` flag because neither of its three supported filesystems (FATFS, LitteLF and Spiffs) has symbolic links in the first place.
What this fix does is to keep the `set_permissions_nofollow` method available and non-failing for ESP-IDF, but it behaves as if no `O_NONFOLLOW` was set. This should be fine as there is nothing to follow in the first place, as there are no symbolic links there.
EDIT: Also added the same fix for Horizon, as requested by `@Meziu.`
Add assembly test for `-Zreg-struct-return` option
r? `@tgross35`
As discussed in rust-lang/rust#145309 with `@tgross35` and `@ojeda,` I added assembly tests for the `-Zreg-struct-return` option verifying that it changes the ABI from hidden pointer to register-return on x86_32.
The test covers:
- Direct struct construction, showing register return vs hidden pointer
- External function calls returning structs, showing ABI mismatch handling
Different memory layouts affect ABI mismatch handling, but register returns use the same register allocation regardless of struct field layout (apart from the fact that they use smaller registers for smaller structs, of course).
[Here](https://godbolt.org/z/dcW6rnMG3) is a compiler explorer with 2 examples. Let me know if there is anything more I could add. Since register returns only happen for structs up to the size of 2 registers, I figured testing the pivot value (8 bytes) would be most critical.
Use captures(address) instead of captures(none) for indirect args
While provenance cannot be captured through these arguments, the address / object identity can.
Fixes https://github.com/rust-lang/rust/issues/137668.
r? `@ghost`
rustdoc: a few micro-optimizations targeted at build_impl
Unsure if these will be anything substantial, but the first one at least should git rid of quite a few branches, second one unsure if it's worth it.
r? `@GuillaumeGomez`
This test covers:
* The callee side, making sure that the structs are correctly loaded into registers when `-Zreg-struct-return` is enabled
* The caller side, making sure that callers do receive returned structs in registers when `-Zreg-struct-return` is enabled
Structs of the size of up to 2 registers (8 bytes) can be returned in registers in x86_32.
Therefore, the tests are done with 3 different struct sizes:
* 2 bytes (register returns should happen)
* 8 bytes (last value where register returns should happen)
* 12 bytes (register returns should not happen even when `-Zreg-struct-return` is enabled)
Inherit TCC in debuginfo tests on macOS
macOS has a system for propagating folder permissions, which LLDB disables when spawning processes, which in turn causes debuginfo tests to spam the user with repeated pop-ups asking for permissions. See the code comment for details, as well as the following video for an example of how this looks in practice:
https://github.com/user-attachments/assets/1e54f5b8-9130-4b59-8e92-1db1e58fb361
I stumbled upon the incantation to fix this (`settings set target.inherit-tcc true`) while investigating slowdowns when spawning newly created binaries due to XprotectService, see [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F).
This would allow me to no longer have a `build.build-dir = "/Users/madsmtm/rust-build"` workaround in my `bootstrap.toml`.
Introduce a `[workspace.dependencies`] section in the top-level `Cargo.toml`
It lets us avoid a lot of repetition of crate versions, etc.
I've just done a few as a start. Many more can be done in follow-ups.
r? `@Kobzol`
improve float to_degrees/to_radians rounding comments and impl
This PR makes `to_degrees()` and `to_radians()` float functions more consistent between each other and improves comments around their precision and rounding.
* revise comments explaining why we are using literal or expression
* add unspecified precision comments as we don't guarantee precision
* use expression in `f128::to_degrees()`
* make `f64::to_degrees()` impl consistent with other functions
r? `@tgross35`
Simplify macro generating ToString implementations for `&…&str`
Use deref coercion to let the compiler remove any amount of references. Also use that macro for `Cow` and `String`.
Region inference: Use outlives-static constraints in constraint search
Revise the extra `r: 'static` constraints added upon universe issues to add an explanation, and use that explanation during constraint blame search. This greatly simplifies the region inference logic, which now does not need to reverse-engineer the event that caused a region to outlive `'static`.
This cosmetically changes the output of two UI tests. I blessed them i separate commits with separate motivations, but that can of course be squashed as desired. We probably want that.
The PR was extracted out of rust-lang/rust#130227 and consists of one-third of its functional payload.
r? lcnr
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#142215 (Use -Zmir-opt-level=0 in tests for MIR building)
- rust-lang/rust#143341 (Mention that casting to *const () is a way to roundtrip with from_raw_parts)
- rust-lang/rust#145078 (Fix wrong cache line size of riscv64)
- rust-lang/rust#145290 (Improve std::fs::read_dir docs)
- rust-lang/rust#145335 (Move WTF-8 code from std into core and alloc)
- rust-lang/rust#145904 (Move `riscv64-gc-unknown-linux-musl` from Tier 2 with Host tools to Tier 2)
r? `@ghost`
`@rustbot` modify labels: rollup
Move WTF-8 code from std into core and alloc
This is basically a small portion of rust-lang/rust#129411 with a smaller scope. It *does not*\* affect any public APIs; this code is still internal to the standard library. It just moves the WTF-8 code into `core` and `alloc` so it can be accessed by `no_std` crates like `backtrace`.
> \* The only public API this affects is by adding a `Debug` implementation to `std::os::windows::ffi::EncodeWide`, which was not present before. This is due to the fact that `core` requires `Debug` implementations for all types, but `std` does not (yet) require this. Even though this was ultimately changed to be a wrapper over the original type, not a re-export, I decided to keep the `Debug` implementation so it remains useful.
Like we do with ordinary strings, the tests are still located entirely in `alloc`, rather than splitting them into `core` and `alloc`.
----
Reviewer note: for ease of review, this is split into three commits:
1. Moving the original files into their new "locations"
2. Actually modifying the code to compile.
3. Removing aesthetic changes that were made so that the diff for commit 2 was readable.
You can review commits 1 and 3 to verify these claims, but commit 2 contains the majority of the changes you should care about.
----
API changes: `impl Debug for std::os::windows::ffi::EncodeWide`
Improve std::fs::read_dir docs
Call out early that the results returned can differ across calls / aren't deterministic. This was already mentioned at the bottom of examples, but I think it's worth calling out early, since this caused at least one person (me!) great confusion.
