fix docs & example for `std::os::unix::prelude::FileExt::write_at`
Changelog:
* used `File::create` instead of `File::read` to get a writeable file
* explicity mentioned the bug with `pwrite64` in docs
Unfortunately, I don't think that there is really much we can do about this since the feature has already been stabilised.
We could potentially add a clippy lint warning people on Linux that using `write_at` with the `O_APPEND` flag does not exhibit the behaviour that they would have assumed.
fixes#113627
Allow limited access to `OsString` bytes
This extends #109698 to allow no-cost conversion between `Vec<u8>` and `OsString` as suggested in feedback from `os_str_bytes` crate in #111544.
std: remove an allocation in `Path::with_extension`
`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 required.
This also reduces the memory consumption of the path returned from `Path::with_extension` by using exact capacity instead of using amortized exponential growth.
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](e7fda447e7/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] e7fda447e7/library/std/src/sys/windows/process.rs (L425)
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.
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 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.
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
