| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=ChrisDenton
Update documentation for std::process::Command's new method
In the current documentation, it's not specified that when creating a Command, the .exe extension can be omitted for Windows executables. However, for other types of executable files like .bat or .cmd, the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()` succeeds on my machine while `Command::new("code").spawn().unwrap()` panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in [a comment](https://github.com/rust-lang/rust/blob/e7fda447e7d05b6ca431fc8fe8f489b1fda810bc/library/std/src/sys/windows/process.rs#L425), but it makes sense to mention it at a more visible place.
I've added this clarification to the documentation, which should make it more accurate and helpful for Rust developers working on the Windows platform.
|
|
|
|
|
|
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
|
|
|
|
|
|
In the current documentation, it's not specified that when creating
a Command, the .exe extension can be omitted for Windows executables.
However, for other types of executable files like .bat or .cmd,
the complete filename including the extension must be provided.
I encountered it by noticing that `Command::new("wt").spawn().unwrap()`
succeeds on my machine while `Command::new("code").spawn().unwrap()`
panics. Turns out VS Code's entrypoint is .cmd file.
`resolve_exe` method mentions this behaviour in a comment[1], but it
makes sense to mention it at more visible place.
I've added this clarification to the documentation, which should
make it more accurate and helpful for Rust developers
working on the Windows platform.
[1] https://github.com/rust-lang/rust/blob/e7fda447e7d05b6ca431fc8fe8f489b1fda810bc/library/std/src/sys/windows/process.rs#L425
|
|
|
|
|
|
|
|
APC (API change proposal): https://github.com/rust-lang/libs-team/issues/237
|
|
|
|
Like the other CStr and CString error types, make a re-export for
std::ffi::FromBytesUntilNulError.
This seems to have slipped through the cracks in the
cstr_from_bytes_until_nul implementation and core_c_str migration.
Tracking Issue: #95027
|
|
update ancient note
|
|
Adjustments for RustyHermit
The interface between `libstd` and the OS changed and some changes are not correctly merged for RustHermit. For instance, the crate `hermit_abi` isn't defined as public, although it provided the socket interface for the application.
In addition, the support of thread::available_parallelism is realized. It returns the number of available processors.
|
|
|
|
See https://github.com/rust-lang/rust/pull/113618#pullrequestreview-1526295432
|
|
|
|
On RustyHermit, the function `get_processor_count` returns the
number of activated processors.
|
|
|
|
Add back BorrowedBuf::filled_mut
This is useful if you want to do some processing on the bytes while still using the BorrowedBuf.
The API was removed in https://github.com/rust-lang/rust/pull/97015 with no explanation. The RFC also has it as part of its API, so this just seems like a mistake: [RFC](https://rust-lang.github.io/rfcs/2930-read-buf.html#:~:text=inline%5D%0A%20%20%20%20pub%20fn-,filled_mut,-(%26mut%20self))
ACP: https://github.com/rust-lang/libs-team/issues/139
|
|
See https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/stat.h
for reference.
|
|
Add `Read`, `Write` and `Seek` impls for `Arc<File>` where appropriate
If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
|
|
move personality to sys
this moves `personality` to sys, removing another PAL exception
|
|
|
|
move pal cfgs in f32 and f64 to sys
I'd like to push forward on `sys` being a separate crate. To start with, most of these PAL exception cases are very simple little bits of code like this, so I thought I would try tidying them up.
|
|
|
|
- copying from `&[u8]` and `VecDeque<u8>`
- copying to `Vec<u8>`
|
|
This extends #109698 to allow no-cost conversion between `Vec<u8>` and `OsString`
as suggested in feedback from `os_str_bytes` crate in #111544.
|
|
Fix incorrect documented default bufsize in bufreader/writer
|
|
Revert the lexing of `c"…"` string literals
Fixes \[after beta-backport\] #113235.
Further progress is tracked in #113333.
This PR *manually* reverts parts of #108801 (since a git-revert would've been too coarse-grained & messy)
and git-reverts #111647.
CC `@fee1-dead` (#108801) `@klensy` (#111647)
r? `@compiler-errors`
`@rustbot` label F-c_str_literals beta-nominated
|
|
This reverts commit f212ba6d6d60963c8101bb24fc3e53fca80c046f.
|
|
This reverts commit 2f459f7f140307b5abbb7ea81440ed1843b490e7.
|
|
Return `Ok` on kill if process has already exited
This will require an FCP from `@rust-lang/libs-api.`
Fixes #112423. See that issue for more details.
|
|
|
|
|
|
std docs: factorize literal in Barrier example
Motivated by https://www.reddit.com/r/rust/comments/rnh5hu/barrier_question_barrier_does_not_sync_many/ (but maybe not worth it?)
|
|
|
|
|
|
|
|
`Path::with_extension` used to reallocate (and copy) paths twice per
call, now it does it once, by checking the size of the previous and new
extensions it's possible to call `PathBuf::with_capacity` and pass the
exact capacity it takes.
Also reduce the memory consumption of the path returned from
`Path::with_extension` by using exact capacity instead of using
amortized exponential growth.
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Move windows-sys arm32 shim to c.rs
This moves the arm32 shim in to c.rs instead of appending to the generated file itself.
This makes it simpler to change these workarounds if/when needed. The downside is we need to exclude a couple of functions from being generated (see the comment). A metadata solution could help here but they'll be easy enough to add back if that happens.
|
|
Remove unnecessary `path` attribute
Follow up to #111401. I missed this at the time but it should now be totally unnecessary since the other include was removed.
r? `@workingjubilee`
|
|
DirEntry::file_name: improve explanation
|
|
|
|
|
|
Implement `Sync` for `mpsc::Sender`
`mpsc::Sender` is currently `!Sync` because the previous implementation contained an optimization where the channel started out as single-producer and was dynamically upgraded on the first clone, which relied on a unique reference to the sender. This optimization is one of the main reasons the old implementation was so complex and was removed in #93563. `mpsc::Sender` can now soundly implement `Sync`.
Note for any potential confusion, this chance does *not* add MPMC behavior. This only affects the already `Send + Clone` *sender*, not *receiver*.
It's technically possible to rely on the `!Sync` behavior in the same way as a `PhantomData<*mut T>`, but that seems very unlikely in practice. Either way, this change is insta-stable and needs an FCP.
`@rustbot` label +T-libs-api -T-libs
|
|
If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
|
|
This reduces code duplication.
|
