| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
file list for the makefile
|
|
|
|
|
|
|
|
Small optimization for integers Display implementation
This is a first pass to try to speed up a bit integers `Display` implementation. The idea behind this is to reduce the stack usage for the buffer storing the output (shouldn't be visible in bench normally) and some small specialization which benefits a lot to smaller integers like `u8` and `i8`.
Here are the results of the benchmarks:
| bench name | current std | with this PR |
|-|-|-|
| bench_std_fmt::bench_i16_0 | 16.45 ns/iter (+/- 0.25) | 16.50 ns/iter (+/- 0.15) |
| bench_std_fmt::bench_i16_max | 17.83 ns/iter (+/- 0.66) | 17.58 ns/iter (+/- 0.10) |
| bench_std_fmt::bench_i16_min | 20.97 ns/iter (+/- 0.49) | 20.50 ns/iter (+/- 0.28) |
| bench_std_fmt::bench_i32_0 | 16.63 ns/iter (+/- 0.06) | 16.62 ns/iter (+/- 0.07) |
| bench_std_fmt::bench_i32_max | 19.79 ns/iter (+/- 0.43) | 19.55 ns/iter (+/- 0.14) |
| bench_std_fmt::bench_i32_min | 22.97 ns/iter (+/- 0.50) | 22.08 ns/iter (+/- 0.08) |
| bench_std_fmt::bench_i64_0 | 16.63 ns/iter (+/- 0.39) | 16.69 ns/iter (+/- 0.44) |
| bench_std_fmt::bench_i64_half | 19.60 ns/iter (+/- 0.05) | 19.10 ns/iter (+/- 0.05) |
| bench_std_fmt::bench_i64_max | 25.22 ns/iter (+/- 0.34) | 24.43 ns/iter (+/- 0.02) |
| bench_std_fmt::bench_i8_0 | 16.27 ns/iter (+/- 0.32) | 15.80 ns/iter (+/- 0.17) |
| bench_std_fmt::bench_i8_max | 16.71 ns/iter (+/- 0.09) | 16.25 ns/iter (+/- 0.01) |
| bench_std_fmt::bench_i8_min | 20.07 ns/iter (+/- 0.22) | 19.80 ns/iter (+/- 0.30) |
| bench_std_fmt::bench_u128_0 | 21.37 ns/iter (+/- 0.24) | 21.35 ns/iter (+/- 0.35) |
| bench_std_fmt::bench_u128_max | 48.13 ns/iter (+/- 0.20) | 48.78 ns/iter (+/- 0.29) |
| bench_std_fmt::bench_u16_0 | 16.48 ns/iter (+/- 0.46) | 16.03 ns/iter (+/- 0.39) |
| bench_std_fmt::bench_u16_max | 17.31 ns/iter (+/- 0.32) | 17.41 ns/iter (+/- 0.32) |
| bench_std_fmt::bench_u16_min | 16.40 ns/iter (+/- 0.45) | 16.02 ns/iter (+/- 0.39) |
| bench_std_fmt::bench_u32_0 | 16.17 ns/iter (+/- 0.04) | 16.29 ns/iter (+/- 0.16) |
| bench_std_fmt::bench_u32_max | 19.00 ns/iter (+/- 0.10) | 19.16 ns/iter (+/- 0.28) |
| bench_std_fmt::bench_u32_min | 16.16 ns/iter (+/- 0.09) | 16.28 ns/iter (+/- 0.11) |
| bench_std_fmt::bench_u64_0 | 16.22 ns/iter (+/- 0.22) | 16.14 ns/iter (+/- 0.18) |
| bench_std_fmt::bench_u64_half | 19.25 ns/iter (+/- 0.07) | 18.95 ns/iter (+/- 0.05) |
| bench_std_fmt::bench_u64_max | 24.31 ns/iter (+/- 0.08) | 24.18 ns/iter (+/- 0.08) |
| bench_std_fmt::bench_u8_0 | 15.76 ns/iter (+/- 0.08) | 15.66 ns/iter (+/- 0.08) |
| bench_std_fmt::bench_u8_max | 16.53 ns/iter (+/- 0.03) | 16.29 ns/iter (+/- 0.02) |
| bench_std_fmt::bench_u8_min | 15.77 ns/iter (+/- 0.06) | 15.67 ns/iter (+/- 0.02) |
The source code is:
<details>
<summary>source code</summary>
```rust
#![feature(test)]
#![allow(non_snake_case)]
#![allow(clippy::cast_lossless)]
extern crate test;
macro_rules! benches {
($($name:ident($value:expr))*) => {
mod bench_std_fmt {
use std::io::Write;
use test::{Bencher, black_box};
$(
#[bench]
fn $name(b: &mut Bencher) {
let mut buf = Vec::with_capacity(40);
b.iter(|| {
buf.clear();
write!(&mut buf, "{}", black_box($value)).unwrap();
black_box(&buf);
});
}
)*
}
}
}
benches! {
bench_u64_0(0u64)
bench_u64_half(u32::max_value() as u64)
bench_u64_max(u64::max_value())
bench_i64_0(0i64)
bench_i64_half(i32::max_value() as i64)
bench_i64_max(i64::max_value())
bench_u16_0(0u16)
bench_u16_min(u16::min_value())
bench_u16_max(u16::max_value())
bench_i16_0(0i16)
bench_i16_min(i16::min_value())
bench_i16_max(i16::max_value())
bench_u128_0(0u128)
bench_u128_max(u128::max_value())
bench_i8_0(0i8)
bench_i8_min(i8::min_value())
bench_i8_max(i8::max_value())
bench_u8_0(0u8)
bench_u8_min(u8::min_value())
bench_u8_max(u8::max_value())
bench_u32_0(0u32)
bench_u32_min(u32::min_value())
bench_u32_max(u32::max_value())
bench_i32_0(0i32)
bench_i32_min(i32::min_value())
bench_i32_max(i32::max_value())
}
```
</details>
And then I ran the equivalent code (source code below) in callgrind with [callgrind_differ](https://github.com/Ethiraric/callgrind_differ) to generate a nice output and here's the result:
```
core::fmt::num::imp::<impl core::fmt::Display for i16>::fmt | 1300000 | - 70000 - 5.385% 1230000
core::fmt::num::imp::<impl core::fmt::Display for i32>::fmt | 1910000 | - 100000 - 5.236% 1810000
core::fmt::num::imp::<impl core::fmt::Display for i64>::fmt | 2430000 | - 110000 - 4.527% 2320000
core::fmt::num::imp::<impl core::fmt::Display for i8>::fmt | 1080000 | - 170000 - 15.741% 910000
core::fmt::num::imp::<impl core::fmt::Display for u16>::fmt | 960000 | + 10000 + 1.042% 970000
core::fmt::num::imp::<impl core::fmt::Display for u32>::fmt | 1300000 | + 30000 + 2.308% 1330000
core::fmt::num::imp::<impl core::fmt::Display for u8>::fmt | 820000 | - 30000 - 3.659% 790000
```
<details>
<summary>Source code</summary>
```rust
#![feature(test)]
extern crate test;
use std::io::{stdout, Write};
use std::io::StdoutLock;
use test::black_box;
macro_rules! benches {
($handle:ident, $buf:ident, $($name:ident($value:expr))*) => {
$(
fn $name(handle: &mut StdoutLock, buf: &mut Vec<u8>) {
for _ in 0..10000 {
buf.clear();
write!(buf, "{}", black_box($value)).unwrap();
handle.write_all(buf);
}
}
$name(&mut $handle, &mut $buf);
)*
}
}
fn main() {
let mut handle = stdout().lock();
let mut buf = Vec::with_capacity(40);
benches! {
handle, buf,
bench_u64_0(0u64)
bench_u64_half(u32::max_value() as u64)
bench_u64_max(u64::max_value())
bench_i64_0(0i64)
bench_i64_half(i32::max_value() as i64)
bench_i64_max(i64::max_value())
bench_u16_0(0u16)
bench_u16_min(u16::min_value())
bench_u16_max(u16::max_value())
bench_i16_0(0i16)
bench_i16_min(i16::min_value())
bench_i16_max(i16::max_value())
bench_u128_0(0u128)
bench_u128_max(u128::max_value())
bench_i8_0(0i8)
bench_i8_min(i8::min_value())
bench_i8_max(i8::max_value())
bench_u8_0(0u8)
bench_u8_min(u8::min_value())
bench_u8_max(u8::max_value())
bench_i32_0(0i32)
bench_i32_min(i32::min_value())
bench_i32_max(i32::max_value())
bench_u32_0(0u32)
bench_u32_min(u32::min_value())
bench_u32_max(u32::max_value())
}
}
```
</details>
The next step would be to specialize the `ToString` implementation so it doesn't go through the `Display` trait. I'm not sure if it will improve anything but I think it's worth a try.
r? `@Amanieu`
|
|
Rollup of 4 pull requests
Successful merges:
- #130005 (Replace -Z default-hidden-visibility with -Z default-visibility)
- #130229 (ptr::add/sub: do not claim equivalence with `offset(c as isize)`)
- #130773 (Update Unicode escapes in `/library/core/src/char/methods.rs`)
- #130933 (rustdoc: lists items that contain multiple paragraphs are more clear)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: lists items that contain multiple paragraphs are more clear
fixes https://github.com/rust-lang/rust/issues/130622
before: 
after:
|
|
Update Unicode escapes in `/library/core/src/char/methods.rs`
`char::MAX` is inconsistent on how Unicode escapes should be formatted. This PR resolves that.
|
|
ptr::add/sub: do not claim equivalence with `offset(c as isize)`
In https://github.com/rust-lang/rust/pull/110837, the `offset` intrinsic got changed to also allow a `usize` offset parameter. The intention is that this will do an unsigned multiplication with the size, and we have UB if that overflows -- and we also have UB if the result is larger than `usize::MAX`, i.e., if a subsequent cast to `isize` would wrap. ~~The LLVM backend sets some attributes accordingly.~~
This updates the docs for `add`/`sub` to match that intent, in preparation for adjusting codegen to exploit this UB. We use this opportunity to clarify what the exact requirements are: we compute the offset using mathematical multiplication (so it's no problem to have an `isize * usize` multiplication, we just multiply integers), and the result must fit in an `isize`.
Cc `@rust-lang/opsem` `@nikic`
https://github.com/rust-lang/rust/pull/130239 updates Miri to detect this UB.
`sub` still has some cases of UB not reflected in the underlying intrinsic semantics (and Miri does not catch): when we subtract `usize::MAX`, then after casting to `isize` that's just `-1` so we end up adding one unit without noticing any UB, but actually the offset we gave does not fit in an `isize`. Miri will currently still not complain for such cases:
```rust
fn main() {
let x = &[0i32; 2];
let x = x.as_ptr();
// This should be UB, we are subtracting way too much.
unsafe { x.sub(usize::MAX).read() };
}
```
However, the LLVM IR we generate here also is UB-free. This is "just" library UB but not language UB.
Cc `@saethlin;` might be worth adding precondition checks against overflow on `offset`/`add`/`sub`?
Fixes https://github.com/rust-lang/rust/issues/130211
|
|
Replace -Z default-hidden-visibility with -Z default-visibility
Issue #105518
|
|
Rollup of 5 pull requests
Successful merges:
- #130630 (Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly)
- #131042 (Instantiate binders in `supertrait_vtable_slot`)
- #131079 (Update wasm-component-ld to 0.5.9)
- #131085 (make test_lots_of_insertions test take less long in Miri)
- #131088 (add fixme to remove LLVM_ENABLE_TERMINFO when minimal llvm version is 19)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add fixme to remove LLVM_ENABLE_TERMINFO when minimal llvm version is 19
`LLVM_ENABLE_TERMINFO` was removed in llvm 19: https://github.com/llvm/llvm-project/blob/release/19.x/llvm/docs/ReleaseNotes.rst#changes-to-building-llvm; current minimal llvm is 18, so left fixme here.
|
|
make test_lots_of_insertions test take less long in Miri
This is by far the slowest `std` test in Miri, taking >2min in https://github.com/rust-lang/miri-test-libstd CI. So let's make this `count` smaller. The runtime should be quadratic in `count` so reducing it to around 2/3 of it's previous value should cut the total time down to less than half -- making it still the slowest test, but by less of a margin. (And this way we still insert >64 elements into the HashMap, in case that power of 2 matters.)
|
|
Update wasm-component-ld to 0.5.9
This updates the `wasm-component-ld` linker binary for the `wasm32-wasip2` target to 0.5.9, pulling in a few bug fixes and recent updates.
|
|
Instantiate binders in `supertrait_vtable_slot`
`supertrait_vtable_slot` was previously using structural equality when probing for the vtable slot, which led to an ICE since we need a *subtype* match, not an exact match.
Fixes #131027
r? lcnr
|
|
Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly
This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.
This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi.
Refs:
- "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1)
- Register definition in LLVM:
- Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249
- Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332
I have three questions:
- ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile".
However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (https://github.com/rust-lang/rust/pull/111331).
Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121
- ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared".
There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121
- Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (https://github.com/rust-lang/rust/pull/119431)...
Note:
- GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn).
Given that cg_gcc has a similar problem with other architecture (https://github.com/rust-lang/rustc_codegen_gcc/issues/485), I don't feel this is a blocker for this PR, but it is worth mentioning here.
- `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in https://github.com/rust-lang/rust/pull/127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... https://github.com/rust-lang/rust/pull/88245#issuecomment-905559591
cc `@uweigand`
r? `@Amanieu`
`@rustbot` label +O-SystemZ
|
|
Add multi-producer, multi-consumer channel (mpmc)
Closes #125712
Tracking issue: #126840
r? m-ou-se
|
|
MCP: https://github.com/rust-lang/compiler-team/issues/782
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
|
|
Enable `f16` tests on non-GNU Windows
There is a MinGW ABI bug that prevents `f16` and `f128` from being usable on `windows-gnu` targets. This does not affect MSVC; however, we have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests will be enabled. There is no effect for `f128` since the default fallback is `false`.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
|
|
|
|
|
|
|
|
Stabilize expr_2021 fragment specifier in all editions
This is part of the `expr`/`expr_2021` fragment specifier for Edition 2024 (#123742). The RFC says we can support expr_2021 in as many editions as is practical, and there's nothing particularly hard about supporting it all the way back to 2015.
In editions 2021 and earlier, `expr` and `expr_2021` are synonyms. Their behavior diverges starting in Edition 2024. This is checked by the `expr_2021_inline_const.rs` test.
cc `@vincenzopalazzo` `@rust-lang/wg-macros` `@traviscross`
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
Co-authored-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
|
|
rustdoc: rewrite stability inheritance as a doc pass
Since doc inlining can almost arbitrarily change the module hierarchy, we can't just use the HIR ancestors of an item to compute its effective stability. This PR moves the stability inheritance that I implemented in https://github.com/rust-lang/rust/pull/130798 into a new doc pass `propagate-stability` that runs after doc inlining and uses the post-inlining ancestors of an item to correctly compute its effective stability.
fixes https://github.com/rust-lang/rust/issues/131020
r? `@notriddle`
|
|
There is a MinGW ABI bug that prevents `f16` and `f128` from being
usable on `windows-gnu` targets. This does not affect MSVC; however, we
have `f16` and `f128` tests disabled on all Windows targets.
Update the gating to only affect `windows-gnu`, which means `f16` tests
will be enabled. There is no effect for `f128` since the default
fallback is `false`.
|
|
r=notriddle,jyn514
Add `field@` and `variant@` doc-link disambiguators
I'm not sure if this is big enough to need an fcp or not, but this is something I found missing when trying to refer to a field in macro-generated docs, not knowing if a method might be defined as well. Obviously, there are definitely other uses.
In the case where it's not disambiguated, methods (and I suppose other associated items in the value namespace) still take priority, which `@jyn514` said was an oversight but I think is probably the desired behavior 99% of the time anyway - shadowing a field with an accessor method is a very common pattern. If fields and methods with the same name started conflicting, it would be a breaking change. Though, to quote them:
> jyn: maybe you can break this only if both [the method and the field] are public
> jyn: rustc has some future-incompat warning level
> jyn: that gets through -A warnings and --cap-lints from cargo
That'd be out of scope of this PR, though.
Fixes #80283
|
|
This updates the `wasm-component-ld` linker binary for the
`wasm32-wasip2` target to 0.5.9, pulling in a few bug fixes and recent
updates.
|
|
Rollup of 5 pull requests
Successful merges:
- #129638 (Hook up std::net to wasi-libc on wasm32-wasip2 target)
- #130877 (rustc_target: Add RISC-V atomic-related features)
- #130914 (Mark some more types as having insignificant dtor)
- #130961 (Enable `f16` tests on x86 Apple platforms)
- #130966 (make ptr metadata functions callable from stable const fn)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
make ptr metadata functions callable from stable const fn
So far this was done with a bunch of `rustc_allow_const_fn_unstable`. But those should be the exception, not the norm. If we are confident we can expose the ptr metadata APIs *indirectly* in stable const fn, we should just mark them as `rustc_const_stable`. And we better be confident we can do that since it's already been done a while ago. ;)
In particular this marks two intrinsics as const-stable: `aggregate_raw_ptr`, `ptr_metadata`. This should be uncontroversial, they are trivial to implement in the interpreter.
Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`
|
|
Enable `f16` tests on x86 Apple platforms
These were disabled because Apple uses a special ABI for `f16`. `compiler-builtins` merged a fix for this in [1], which has since propagated to rust-lang/rust. Enable tests since there should be no remaining issues on these platforms.
[1]: https://github.com/rust-lang/compiler-builtins/pull/675
try-job: x86_64-apple-1
try-job: x86_64-apple-2
|
|
Mark some more types as having insignificant dtor
These were caught by https://github.com/rust-lang/rust/pull/129864#issuecomment-2376658407, which is implementing a lint for some changes in drop order for temporaries in tail expressions.
Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory.
See some discussion on #89144 for what makes a drop impl "significant"
|
|
rustc_target: Add RISC-V atomic-related features
This adds the following three target features to unstable riscv_target_feature.
- `zaamo` (Zaamo Extension 1.0.0): Atomic Memory Operations (`amo*.{w,d}{,.aq,.rl,.aqrl}`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L229-L231), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/8be079cdddfd628d356d9ddb5ab397ea95fb1030))
- `zabha` (Zabha Extension 1.0.0): Byte and Halfword Atomic Memory Operations (`amo*.{b,h}{,.aq,.rl,.aqrl}`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L238-L240), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/6b7444964a8d028989beee554a1f5c61d16a1cac))
- `zalrsc` (Zalrsc Extension 1.0.0): Load-Reserved/Store-Conditional Instructions (`lr.{w,d}{,.aq,.rl,.aqrl}` and `sc.{w,d}{,.aq,.rl,.aqrl}`)
([definition in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L261-L263), [available since LLVM 19](https://github.com/llvm/llvm-project/commit/8be079cdddfd628d356d9ddb5ab397ea95fb1030))
(Zacas Extension is not included here because it is still marked as experimental in LLVM 19 https://github.com/llvm/llvm-project/commit/70e7d26e560173c8b9db4c75ab4a3004cd5f021a and will become non-experimental in LLVM 20 https://github.com/llvm/llvm-project/commit/614aeda93b2225c6eb42b00ba189ba7ca2585c60)
`a` implies `zaamo` and `zalrsc`, and `zabha` implies `zaamo`:
- After Zaamo and Zalrsc Extensions are frozen, riscv-isa-manual says "The A extension comprises instructions provided by the Zaamo and Zalrsc extensions" (https://github.com/riscv/riscv-isa-manual/commit/e87412e621f11f4aac61a3b9d5e73e98a64b3432), and [`a` implies `zaamo` and `zalrsc` in GCC](https://github.com/gcc-mirror/gcc/blob/08693e29ec186fd7941d0b73d4d466388971fe2f/gcc/config/riscv/arch-canonicalize#L44). However, in LLVM, [`a` does not define them as implying `zaamo` and `zalrsc`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L206).
- Zabha and Zaamo are in a similar situation, [riscv-isa-manual](https://github.com/riscv/riscv-isa-manual/blob/main/src/zabha.adoc) says "The Zabha extension depends upon the Zaamo standard extension", and [`zabha` implies `zaamo` in GCC](https://github.com/gcc-mirror/gcc/blob/08693e29ec186fd7941d0b73d4d466388971fe2f/gcc/config/riscv/arch-canonicalize#L45-L46), but [does not in LLVM (but enabling `zabha` without `zaamo` or `a` is not allowed)](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/TargetParser/RISCVISAInfo.cpp#L776-L778).
r? `@Amanieu`
`@rustbot` label +O-riscv +A-target-feature
|
|
Hook up std::net to wasi-libc on wasm32-wasip2 target
One of the improvements of the `wasm32-wasip2` target over `wasm32-wasip1` is better support for networking. Right now, p2 is just re-using the `std::net` implementation from p1. This PR adds a new net module for p2 that makes use of net from `sys_common` and calls wasi-libc functions directly.
There are currently a few limitations:
- Duplicating a socket is not supported by WASIp2 (directly returns an error)
- Peeking is not yet implemented in wasi-libc (we could let wasi-libc handle this, but I opted to directly return an error instead)
- Vectored reads/writes are not supported by WASIp2 (the necessary functions are available in wasi-libc, but they call WASIp1 functions which do not support sockets, so I opted to directly return an error instead)
- Getting/setting `TCP_NODELAY` is faked in wasi-libc (uses the fake implementation instead of returning an error)
- Getting/setting `SO_LINGER` is not supported by WASIp2 (directly returns an error)
- Setting `SO_REUSEADDR` is faked in wasi-libc (since this is done from `sys_common`, the fake implementation is used instead of returning an error)
- Getting/setting `IPV6_V6ONLY` is not supported by WASIp2 and will always be set for IPv6 sockets (since this is done from `sys_common`, wasi-libc will return an error)
- UDP broadcast/multicast is not supported by WASIp2 (since this is configured from `sys_common`, wasi-libc will return appropriate errors)
- The `MSG_NOSIGNAL` send flag is a no-op because there are no signals in WASIp2 (since explicitly setting this flag would require a change to `sys_common` and the result would be exactly the same, I opted to not set it)
Do those decisions make sense?
While working on this PR, I noticed that there is a `std::os::wasi::net::TcpListenerExt` trait that adds a `sock_accept()` method to `std::net::TcpListener`. Now that WASIp2 supports standard accept, would it make sense to remove this?
cc `@alexcrichton`
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #131023 (Copy correct path to clipboard for modules/keywords/primitives)
- #131035 (Preserve brackets around if-lets and skip while-lets)
- #131038 (Fix `adt_const_params` leaking `{type error}` in error msg)
- #131053 (Improve `--print=check-cfg` documentation)
- #131056 (enable compiler fingerprint logs in verbose mode)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
