| Age | Commit message (Collapse) | Author | Lines |
|
This reverts commit b89b0567427932fe37851a314610d795258f1834.
|
|
This reverts commit 949b978ec9d63b0eea23d89bad16c6f022ac34a3.
|
|
This reverts commit 1e7c15634d3b81b595d669382e45e6e136c730e1.
|
|
Use Rust 2021 prelude in std itself.
|
|
|
|
|
|
[feat] Make sys::windows::os_str::Slice repr(transparent)
Fixes #96577
|
|
|
|
|
|
|
|
Windows: Make stdin pipes synchronous
Stdin pipes do not need to be used asynchronously within the standard library. This is a first step in making pipes mostly synchronous.
r? `@m-ou-se`
|
|
std: directly use pthread in UNIX parker implementation
`Mutex` and `Condvar` are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore we should use the `pthread` synchronization primitives directly. Also, we can avoid allocating the mutex and condition variable because the `Parker` struct is being placed in an `Arc` anyways.
This basically is just a copy of the current `Mutex` and `Condvar` code, which will however be removed (again, see #93740). An alternative implementation could be to use dedicated private `OsMutex` and `OsCondvar` types, but all the other platforms supported by std actually have their own thread parking primitives.
I used `Pin` to guarantee a stable address for the `Parker` struct, while the current implementation does not, rather using extra unsafe declaration. Since the thread struct is shared anyways, I assumed this would not add too much clutter while being clearer.
|
|
|
|
Stdin pipes do not need to be used asynchronously within the standard library.
|
|
|
|
Mutex and Condvar are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore use the pthread synchronization primitives directly. Also, avoid allocating because the Parker struct is being placed in an Arc anyways.
|
|
Windows Command: Don't run batch files using verbatim paths
Fixes #95178
Note that the first commit does some minor refactoring (moving command line argument building to args.rs). The actual changes are in the second.
|
|
Reduce allocations for path conversions on Windows
Previously, UTF-8 to UTF-16 Path conversions on Windows unnecessarily allocate twice, as described in #96297. This commit fixes that issue.
|
|
Improve Windows path prefix parsing
This PR fixes improves parsing of Windows path prefixes. `parse_prefix` now supports both types of separators on Windows (`/` and `\`).
|
|
|
|
Previously, UTF-8 to UTF-16 Path conversions on Windows unnecessarily allocate twice, as described in #96297. This commit fixes that issue.
|
|
|
|
|
|
library: Move `CStr` to libcore, and `CString` to liballoc
Closes https://github.com/rust-lang/rust/issues/46736
Interesting points:
- Stability:
- To make `CStr(ing)` from libcore/liballoc unusable without enabling features I had to make these structures unstable, and reexport them from libstd using stable type aliases instead of `pub use` reexports. (Because stability of `use` items is not checked.)
- Relying on target ABI in libcore is ok:
- https://github.com/rust-lang/rust/pull/94079#issuecomment-1044263371
- `trait CStrExt` (UPDATE: used only in `cfg(bootstrap)` mode, otherwise lang items are used instead)
- https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450
- `strlen`
- https://github.com/rust-lang/rust/pull/94079#issuecomment-1047863450
Otherwise it's just a code move + some minor hackery usual for liballoc in `cfg(test)` mode.
|
|
Windows: Use a pipe relay for chaining pipes
Fixes #95759
This fixes the issue by chaining pipes synchronously and manually pumping messages between them. It's not ideal but it has the advantage of not costing anything if pipes are not chained ("don't pay for what you don't use") and it also avoids breaking existing code that rely on our end of the pipe being asynchronous (which includes rustc's own testing framework).
Libraries can avoid needing this by using their own pipes to chain commands.
|
|
|
|
fix unused constant warning on some Windows targets
When none of those `cfg_if!` apply (and on Miri), the constant remains unused.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #95102 (Add known-bug for #95034)
- #95579 (Add `<[[T; N]]>::flatten{_mut}`)
- #95634 (Mailmap update)
- #95705 (Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts)
- #95761 (Kickstart the inner usage of `macro_metavar_expr`)
- #95782 (Windows: Increase a pipe's buffer capacity to 64kb)
- #95791 (hide an #[allow] directive from the Arc::new_cyclic doc example)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
make windows compat_fn (crudely) work on Miri
With https://github.com/rust-lang/rust/pull/95469, Windows `compat_fn!` now has to be supported by Miri to even make stdout work. Unfortunately, it relies on some outside-of-Rust linker hacks (`#[link_section = ".CRT$XCU"]`) that are rather hard to make work in Miri. So I came up with this crude hack to make this stuff work in Miri regardless. It should come at no cost for regular executions, so I hope this is okay.
Cc https://github.com/rust-lang/rust/issues/95627 `@ChrisDenton`
|
|
This brings it inline with typical Linux defaults: https://www.man7.org/linux/man-pages/man7/pipe.7.html
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Windows: Synchronize asynchronous pipe reads and writes
On Windows, the pipes used for spawned processes are opened for asynchronous access but `read` and `write` are done using the standard methods that assume synchronous access. This means that the buffer (and variables on the stack) may be read/written to after the function returns.
This PR ensures reads/writes complete before returning. Note that this only applies to pipes we create and does not affect the standard file read/write methods.
Fixes #95411
|
|
|
|
|
|
|
|
Some things like the unwinders and system APIs are not fully conformant,
this only covers a lot of low-hanging fruit.
|
|
And also fix typo.
|
|
Move std::sys::{mutex, condvar, rwlock} to std::sys::locks.
This cleans up the the std::sys modules a bit by putting the locks in a single module called `locks` rather than spread over the three modules `mutex`, `condvar`, and `rwlock`. This makes it easier to organise lock implementations, which helps with https://github.com/rust-lang/rust/issues/93740.
|
|
|
|
|
|
|
|
|