Stabilize feature `cstr_from_bytes_until_nul`
This PR seeks to stabilize `cstr_from_bytes_until_nul`.
Partially addresses #95027
This function has only been on nightly for about 10 months, but I think it is simple enough that there isn't harm discussing stabilization. It has also had at least a handful of mentions on both the user forum and the discord, so it seems like it's already in use or at least known.
This needs FCP still.
Comment on potential discussion points:
- eventual conversion of `CStr` to be a single thin pointer: this function will still be useful to provide a safe way to create a `CStr` after this change.
- should this return a length too, to address concerns about the `CStr` change? I don't see it as being particularly useful, and it seems less ergonomic (i.e. returning `Result<(&CStr, usize), FromBytesUntilNulError>`). I think users that also need this length without the additional `strlen` call are likely better off using a combination of other methods, but this is up for discussion
- `CString::from_vec_until_nul`: this is also useful, but it doesn't even have a nightly implementation merged yet. I propose feature gating that separately, as opposed to blocking this `CStr` implementation on that
Possible alternatives:
A user can use `from_bytes_with_nul` on a slice up to `my_slice[..my_slice.iter().find(|c| c == 0).unwrap()]`. However; that is significantly less ergonomic, and is a bit more work for the compiler to optimize compared the direct `memchr` call that this wraps.
## New stable API
```rs
// both in core::ffi
pub struct FromBytesUntilNulError(());
impl CStr {
pub const fn from_bytes_until_nul(
bytes: &[u8]
) -> Result<&CStr, FromBytesUntilNulError>
}
```
cc ```@ericseppanen``` original author, ```@Mark-Simulacrum``` original reviewer, ```@m-ou-se``` brought up some issues on the thin pointer CStr
```@rustbot``` modify labels: +T-libs-api +needs-fcp
Clarify wording on f64::round() and f32::round()
"Round half-way cases" is a little confusing (it's a 'garden path sentence' as it's not immediately clear whether round is an adjective or verb).
Make this sentence longer and clearer.
"Round half-way cases" is a little confusing (it's a 'garden path
sentence' as it's not immediately clear whether round is an adjective
or verb).
Make this sentence longer and clearer.
Replace unwrap with ? in TcpListener doc
The example in TcpListener doc returns `std::io::Result<()>` but the code inside the function uses `unwrap()` instead of `?`.
Bump bootstrap compiler to 1.68
This also changes our stage0.json to include the rustc component for the rustfmt pinned nightly toolchain, which is currently necessary due to rustfmt dynamically linking to that toolchain's librustc_driver and libstd.
r? `@pietroalbini`
bootstrap: cleanup the list of extra check cfgs
This PR performs some cleanups on the `EXTRA_CHECK_CFGS` list in bootstrap.
- `target_os=watchos`: no longer relevant because there are now proper targets `*-apple-watchos`
- `target_arch=nvptx64`: target `nvptx64-nvidia-cuda` makes it useless
- `target_arch=le32`: target was removed (https://github.com/rust-lang/rust/pull/45041)
- `release`: was removed from rustfmt (https://github.com/rust-lang/rustfmt/pull/5375 and https://github.com/rust-lang/rustfmt/pull/5449)
- `dont_compile_me`: was removed from stdarch (https://github.com/rust-lang/stdarch/pull/1308)
Also made some external cfg exception mode clear and only activated for rustc and rustc tools (as to not have the Standard Library unintentionally depend on them).
library/std/sys_common: Define MIN_ALIGN for m68k-unknown-linux-gnu
This PR adds the missing definition of MIN_ALIGN for the m68k-unknown-linux target.
Disable `linux_ext` in wasm32 and fortanix rustdoc builds.
The `std::os::unix` module is stubbed out when building docs for these target platforms. The introduction of Linux-specific extension traits caused `std::os::net` to depend on sub-modules of `std::os::unix`, which broke rustdoc for the `wasm32-unknown-unknown` target.
Adding an additional `#[cfg]` guard solves that rustdoc failure by not declaring `linux_ext` on targets with a stubbed `std::os::unix`.
Fixes#105467
Replace libc::{type} with crate::ffi::{type}
Replace libc::{type} imports with crate::ffi::{type} outside of `std::sys` and `std::os`.
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Stabilize the const_socketaddr feature
Stabilizes `#![feature(const_socketaddr)]`. Tracking issue: #82485Closes#82485
This has been unstably const for over a year now. And the code change simplifying the constness of the `new` constructors has been in stable Rust since 1.64 (a bit over a full release cycle). I'm not aware of any blockers to this stabilization.
Avoid __cxa_thread_atexit_impl on Emscripten
- Fixes https://github.com/rust-lang/rust/issues/91628.
- Fixes https://github.com/emscripten-core/emscripten/issues/15722.
See discussion in both issues.
The TL;DR is that weak linkage causes LLVM to produce broken Wasm, presumably due to pointer mismatch. The code is casting a void pointer to a function pointer with specific signature, but Wasm is very strict about function pointer compatibility, so the resulting code is invalid.
Ideally LLVM should catch this earlier in the process rather than emit invalid Wasm, but it currently doesn't and this is an easy and valid fix, given that Emcripten doesn't have `__cxa_thread_atexit_impl` these days anyway.
Unfortunately, I can't add a regression test as even after looking into this issue for a long time, I couldn't reproduce it with any minimal Rust example, only with extracted LLVM IR or on a large project involving Rust + C++.
Do not use box syntax in `std`
See #94970 and #49733. About half of the `box` instances in `std` do not even need to allocate, the other half can simply be replaced with `Box::new`.
`@rustbot` label +T-libs
r? rust-lang/libs
Add note about absolute paths to Path::join
The note already exists on `PathBuf::push`, but I think it is good to have it on `Path::join` as well since it can cause issues if you are not careful with your input.
Fix the stability attributes for `std::os::fd`.
As `@bjorn3` pointed out [here], I used the wrong stability attribute in #98368 when making `std::os::fd` public. I set it to Rust 1.63, which was when io-safety was stabilized, but it should be Rust 1.66, which was when `std::os::fd` was stabilized.
[here]: https://github.com/rust-lang/rust/pull/98368#discussion_r1063721420
As @bjorn3 pointed out [here], I used the wrong stability attribute in #98368
when making `std::os::fd` public. I set it to Rust 1.63, which was when
io-safety was stabilized, but it should be Rust 1.66, which was when
`std::os::fd` was stabilized.
[here]: https://github.com/rust-lang/rust/pull/98368#discussion_r1063721420
Remove various double spaces in the libraries.
I was just pretty bothered by this when reading the source for a function, and was suggested to check if this happened elsewhere.
Stop probing for statx unless necessary
As is the current toy program:
fn main() -> std::io::Result<()> {
use std::fs;
let metadata = fs::metadata("foo.txt")?;
assert!(!metadata.is_dir());
Ok(())
}
... observed under strace will issue:
[snip]
statx(0, NULL, AT_STATX_SYNC_AS_STAT, STATX_ALL, NULL) = -1 EFAULT (Bad address) statx(AT_FDCWD, "foo.txt", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
While statx is not necessarily always present, checking for it can be delayed to the first error condition. Said condition may very well never happen, in which case the check got avoided altogether.
Note this is still suboptimal as there still will be programs issuing it, but bulk of the problem is removed.
Tested by forbidding the syscall for the binary and observing it correctly falls back to newfstatat.
While here tidy up the commentary, in particular by denoting some problems with the current approach.
Michael Goulet
