specify explicit safety guidance for from_utf8_unchecked
The PR addresses missing safety guidelines in two APIs by adding explicit text to the cross-linked reference.
docs: fix incorrect stability markers on `std::{todo, matches}`
This regression appeared in 916cfbcd3e. The change is behaving as expected (a non-glob re-export uses the stability marker on the `use` item, not the original one), but this part of the standard library didn't follow it.
Fixes https://github.com/rust-lang/rust/issues/140344
fix(test): Expose '--no-capture' in favor of `--nocapture`
This improves consistency with commonly expected CLI conventions,
avoiding a common stutter people make when running tests (trying what
they expect and then having to check the docs to then user whats
accepted).
An alternative could have been to take a value, like `--capture <value>` (e.g. `pytest` does this).
Overall, we're shifting focus for features to custom test harnesses (see #134283).
Most of `pytest`s modes will likely be irrelevant in that situation.
As for the rest, its too early to tell which, if any, may be relevant,
so we're sticking with this small, quality of life improvement.
I expect we'll warn about `--nocapture` being deprecated in the future after a sufficient transition period has been allowed.
By deprecating `--nocapture`, we intend that custom test harnesses do
not need to support it for reasons outside of their own compatibility
requirements, much like the deprecation in #134283
I'm punting for now on the naming of `RUST_TEST_NOCAPTURE`.
I feel like T-testing-devex should do a wider look at environment
variables role in lib`test` before evaluating whether to
- Deprecate it in favor of the user passing CLI flags or the test runner
providing its own config
- Deprecate in favor of `RUST_TEST_NO_CAPTURE`
- Deprecate in favor of `RUST_TEST_CAPTURE`
Other CLI flags were evaluated for casing consistency:
- `--logfile` has the same problem but was deprecated in #134283
Regarding the implementation, I moved `--nocapture` out of `optgroups()`, into `parse_opts()`, out of an abundance of caution in passing the options without a deprecated value to the usage generation. However, the usage does not actually show optional flags, so this could potentially be dropped, simplifying the PR.
Note: `compiletest` added `--no-capture` instead of `--nocapture` in #134809
T-testing-devex FCP: https://github.com/rust-lang/rust/issues/133073#issuecomment-2486921104Fixes#133073
Update safety documentation for `CString::from_ptr` and `str::from_boxed_utf8_unchecked`
## PR Description
This PR addresses missing safety documentation for two APIs:
**1. alloc::ffi::CStr::from_raw**
- `Alias`: The pointer must not be aliased (accessed via other pointers) during the reconstructed CString's lifetime.
- `Owning`: Calling this function twice on the same pointer and creating two objects with overlapping lifetimes, introduces two alive owners of the same memory. This may result in a double-free.
- `Dangling`: The prior documentation required the pointer to originate from CString::into_raw, but this constraint is incomplete. A validly sourced pointer can also cause undefined behavior (UB) if it becomes dangling. A simple Poc for this situation:
```
use std::ffi::CString;
use std::os::raw::c_char;
fn create_dangling() -> *mut c_char {
let local_ptr: *mut c_char = {
let valid_data = CString::new("valid").unwrap();
valid_data.into_raw()
};
unsafe {
let _x = CString::from_raw(local_ptr);
}
local_ptr
}
fn main() {
let dangling = create_dangling();
unsafe {let _y = CString::from_raw(dangling);} // Cause UB!
}
```
**2. alloc::str::from_boxed_utf8_unchecked**
- `ValidStr`: Bytes must contain a valid UTF-8 sequence.
Stabilise `std::ffi::c_str`
This finished FCP in #112134 but never actually got a stabilisation PR. Since the FCP in #120048 recently passed to add the `os_str` module, it would be nice to also merge this too, to ensure that both get added in the next version.
Note: The added stability attributes which *somehow* were able to be omitted before (rustc bug?) were added based on the fact that they were added in 302551388b, which ended up in 1.85.0.
Closes: https://github.com/rust-lang/rust/issues/112134
r? libs-api
This regression appeared in 916cfbcd3e.
The change is behaving as expected (a non-glob re-export uses the
stability marker on the `use` item, not the original one), but
this part of the standard library didn't follow it.
Document that "extern blocks must be unsafe" in Rust 2024
The [documentation on `extern`](https://doc.rust-lang.org/std/keyword.extern.html) contains the following code sample:
```rust
#[link(name = "my_c_library")]
extern "C" {
fn my_c_function(x: i32) -> bool;
}
```
Due to #123743, attempting to compile such code with the 2024 edition of Rust fails:
```
error: extern blocks must be unsafe
```
This PR extends the `extern` documentation with a brief explanation of the new requirement. It also adds the missing `unsafe` keyword to the code sample, which should be compatible with rustc since v1.82.
**Related docs:**
- https://doc.rust-lang.org/reference/items/external-blocks.html
- https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-extern.html
Stabilize proc_macro::Span::{start,end,line,column}.
This stabilizes part of https://github.com/rust-lang/rust/issues/54725
Specifically, the part related to getting the location of a span:
```rust
impl Span {
pub fn start(&self) -> Span; // Empty span at the start of this span
pub fn end(&self) -> Span; // Empty span at the end of this span
pub fn line(&self) -> usize; // Line where the span starts
pub fn column(&self) -> usize; // Column where the span starts
}
```
History of this part of the API:
Originally, `start` and `end` returned a `LineColumn` struct (containing the line and column).
This has been simplified/changed:
- No more `LineColumn`: `Span` now directly has `.line()` and `.column()` methods. This means we can easily add `.byte_offset()` or `.byte_range()` in the future if we want to.
- `Span::start()` and `Span::end()` are now the equivalent of rustc's internal `shrink_to_lo()` and `shrink_to_hi()`. This means you can do e.g. `span.end().column()`, removing the need for a `span.end_column()` or similar.
Rollup of 8 pull requests
Successful merges:
- #137683 (Add a tidy check for GCC submodule version)
- #138968 (Update the index of Result to make the summary more comprehensive)
- #139572 (docs(std): mention const blocks in const keyword doc page)
- #140152 (Unify the format of rustc cli flags)
- #140193 (fix ICE in `#[naked]` attribute validation)
- #140205 (Tidying up UI tests [2/N])
- #140284 (remove expect() in `unnecessary_transmutes`)
- #140290 (rustdoc: fix typo change from equivelent to equivalent)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 8 pull requests
Successful merges:
- #137653 (Deprecate the unstable `concat_idents!`)
- #138957 (Update the index of Option to make the summary more comprehensive)
- #140006 (ensure compiler existance of tools on the dist step)
- #140143 (Move `sys::pal::os::Env` into `sys::env`)
- #140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/)
- #140236 (norm nested aliases before evaluating the parent goal)
- #140257 (Some drive-by housecleaning in `rustc_borrowck`)
- #140278 (Don't use item name to look up associated item from trait item)
r? `@ghost`
`@rustbot` modify labels: rollup
Move `sys::pal::os::Env` into `sys::env`
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are publicly exposed via `std::env`, their implementations are each self-contained. Keep them separate in `std::sys` and make a new module, `sys::env`, for `Env`.
Also fix `unsafe_op_in_unsafe_fn` for Unix and update the `!DynSend` and `!DynSync` impls which had grown out of sync with the platforms (see #48005 for discussion on that).
r? joboet
Tracked in #117276.
Update the index of Option to make the summary more comprehensive
fix: #138955
This PR and #138968 are twin PR
By the way, this is my first time contributing to rust, and I'm not a native English speaker, so any suggestions—whether about the wording in the docs or the contribution process itself—would be greatly appreciated!
Deprecate the unstable `concat_idents!`
`concat_idents` has been around unstably for a long time, but there is now a better (but still unstable) way to join identifiers using `${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves a lot of the problems with `concat_idents` and is on a better track toward stabilization, so there is no need to keep both versions around. `concat_idents!` still has a lot of use in the ecosystem so deprecate it before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
Work around cygwin issue on condvar timeout
This workaround *just works*... Actually I don't quite understand why does it work in such way. With a simple test on Cygwin, it seems that the maximum value of `tv_sec` could be 12899331056917, while the maximum value of `tv_nsec` should be a value floating around 464600000. A larger `timespec` could block the syscall forever.
r? `@joboet`
`concat_idents` has been around unstably for a long time, but there is
now a better (but still unstable) way to join identifiers using
`${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves
a lot of the problems with `concat_idents` and is on a better track
toward stabilization, so there is no need to keep both versions around.
`concat_idents!` still has a lot of use in the ecosystem so deprecate it
before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc
implements #136067
Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases.
```rs
fn bytes_at_home(x: [u8; 4]) -> u32 {
transmute(x)
}
// other examples
transmute::<[u8; 2], u16>();
transmute::<[u8; 8], f64>();
transmute::<u32, [u8; 4]>();
transmute::<char, u32>();
transmute::<u32, char>();
```
It would be handy to suggest `u32::from_ne_bytes(x)`.
This is implemented for `[u8; _]` -> `{float int}`
This also implements the cases:
`fXX` <-> `uXX` = `{from_bits, to_bits}`
`uXX` -> `iXX` via `cast_unsigned` and `cast_signed`
{`char` -> `u32`, `bool` -> `n8`} via `from`
`u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested)
`u8` -> `bool` via `==` (debatable)
---
try-job: aarch64-gnu
try-job: test-various
std: Add performance warnings to HashMap::get_disjoint_mut
Closes#139296
The `get_disjoint_mut` in `HashMap` also performs a complexity O(n^2) check. So we need to be reminded of that as well.
b5b0655a37/src/raw/mod.rs (L1216-L1220)
