| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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 multi-producer, multi-consumer channel (mpmc)
Closes #125712
Tracking issue: #126840
r? m-ou-se
|
|
|
|
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"
|
|
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`
|
|
and for renaming over a non-empty directory
|
|
Windows 10 1601 introduced `FileRenameInfoEx` as well as
`FILE_RENAME_FLAG_POSIX_SEMANTICS`, allowing for atomic renaming. If it
isn't supported, we fall back to `FileRenameInfo`.
This commit also replicates `MoveFileExW`'s behavior of checking whether
the source file is a mount point and moving the mount point instead of
resolving the target path.
|
|
|
|
Clarifications for set_nonblocking methods
Closes #129903.
The issue mentions that `send`, `recv` and other operations are interpreted by some users as methods of `TcpSocket` which led to confusion since it hasn't them. To fix it I added "system" into the documentation as being more precise for two reasons:
* it's makes it clear that these names are system operations;
* it doesn't point to the location of these methods like `libc` because not every system is POSIX compatible.
|
|
Update `catch_unwind` doc comments for `c_unwind`
Updates `catch_unwind` doc comments to indicate that catching a foreign exception _will no longer_ be UB. Instead, there are two possible behaviors, though it is not specified which one an implementation will choose.
Nominated for t-lang to confirm that they are okay with making such a promise based on t-opsem FCP, or whether they would like to be included in the FCP.
Related: https://github.com/rust-lang/rust/issues/74990, https://github.com/rust-lang/rust/issues/115285, https://github.com/rust-lang/reference/pull/1226
|
|
|
|
|
|
Reference UNSPECIFIED instead of INADDR_ANY in join_multicast_v4
|
|
Fix `read_buf` uses in `std`
Following lib-team decision here: https://github.com/rust-lang/rust/issues/78485#issuecomment-2122992314
Guard against the pathological behavior of both returning an error and performing a read.
|
|
|
|
|
|
Revert Break into the debugger on panic (129019)
This was talked about a bit at a recent libs meeting. While I think experimenting with this is worthwhile, I am nervous about this new behaviour reaching stable. We've already reverted on one tier 1 platform (Linux, https://github.com/rust-lang/rust/pull/130810) which means we have differing semantics on different tier 1 platforms. Also the fact it triggers even when `catch_unwind` is used to catch the panic means it can be very noisy in some projects.
At the very least I think it could use some more discussion before being instantly stable. I think this could maybe be re-landed with an environment variable to control/override the behaviour. But that part would likely need a libs-api decision.
cc ````@workingjubilee```` ````@kromych````
|
|
Use `mem::offset_of!` for `sockaddr_un.sun_path`
We don't need manual pointer math here anymore!
try-job: dist-i686-msvc
|
|
|
|
Since the stabilization in #127679 has reached stage0, 1.82-beta, we can
start using `&raw` freely, and even the soft-deprecated `ptr::addr_of!`
and `ptr::addr_of_mut!` can stop allowing the unstable feature.
I intentionally did not change any documentation or tests, but the rest
of those macro uses are all now using `&raw const` or `&raw mut` in the
standard library.
|
|
|
|
Add tracking issue for io_error_inprogress
I forgot to mention this in #130789
|
|
add link from random() helper fn to extensive DefaultRandomSource docs
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #130549 (Add RISC-V vxworks targets)
- #130595 (Initial std library support for NuttX)
- #130734 (Fix: ices on virtual-function-elimination about principal trait)
- #130787 (Ban combination of GCE and new solver)
- #130809 (Update llvm triple for OpenHarmony targets)
- #130810 (Don't trap into the debugger on panics under Linux)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Don't trap into the debugger on panics under Linux
This breaks `rr`, see https://github.com/rust-lang/rust/pull/129019#issuecomment-2369361278 for the discussion
CC `@khuey` `@workingjubilee`
|
|
Initial std library support for NuttX
This PR add the initial libstd support for NuttX platform (Tier 3), currently it depends on https://github.com/rust-lang/libc/pull/3909 which provide the essential libc definitions.
|
|
Add RISC-V vxworks targets
Risc-V 32 and RISC-V 64 targets are to be added in the target list.
|
|
|
|
Add `File` constructors that return files wrapped with a buffer
In addition to the light convenience, these are intended to raise visibility that buffering is something you should consider when opening a file, since unbuffered I/O is a common performance footgun to Rust newcomers.
ACP: https://github.com/rust-lang/libs-team/issues/446
Tracking Issue: #130804
|
|
This breaks `rr`, see https://github.com/rust-lang/rust/pull/129019#issuecomment-2369361278
for the discussion
CC @khuey @workingjubilee
|
|
|
|
|
|
|
|
|
|
|
|
Co-authored-by: David Tolnay <dtolnay@gmail.com>
Co-authored-by: nora <48135649+Noratrieb@users.noreply.github.com>
|
|
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
|
|
rustdoc: redesign toolbar and disclosure widgets
Fixes #77899
Fixes #90310
## Preview
| before | after
| ------ | -----
|  | 
|  | 
|  | 
|  | 
|  | 
| N/A | 
|  | 
|  | 
https://notriddle.com/rustdoc-html-demo-12/toolbar-v2/std/index.html
## Description
This adds labels to the icons and moves them away from the search box.
These changes are made together, because they work together, but are based on several complaints:
* The [+/-] thing are a Reddit-ism. They don't look like buttons, but look like syntax <https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/More.20visual.20difference.20for.20the.20.2B.2F-.20.20Icons>, <https://github.com/rust-lang/rust/issues/59851> (some of these are laundry lists with more suggestions, but they all mention [+/-] looking wrong)
* The settings, help, and summary buttons are also too hard to recognize <https://lwn.net/Articles/987070/>, <https://github.com/rust-lang/rust/issues/90310>, <https://github.com/rust-lang/rust/issues/14475#issuecomment-274241997>, <https://internals.rust-lang.org/t/improve-rustdoc-design/12758> ("Not all functionality is self-explanatory, for example the [+] button in the top right corner, the theme picker or the settings button.")
The toggle-all and toggle-individual buttons both need done at once, since we want them to look like they go together. This changes them from both being [+/-] to both being arrows.
CC <https://github.com/rust-lang/rust/pull/113074#issuecomment-1677469680> and ``@jsha`` regarding the use of triangles for disclosure, which is what everyone wanted, but was pending a good toggle-all button. This PR adds a toggle-all button that should work.
Settings and Help are also migrated, so that the whole group can benefit from being described using actual words.
The breadcrumbs also get redesigned, so that they use less space, by shrinking the parent module path parts. This is done at the same time as the toolbar redesign because it's, effectively, moving space from the toolbar to the breadcrumbs.
This is aimed at avoiding any line wrapping at desktop sizes.
## Prior art
This style of toolbar, with explicit labels on the buttons, used to be more popular. It's not very common in web browsers nowadays, and for truly universal icons like :arrow_left: I can understand why, but words are great when icons fail.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implements the ACP https://github.com/rust-lang/libs-team/issues/393.
|
