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
Correctly display stdout and stderr in case a doctest is failing
Fixes https://github.com/rust-lang/rust/issues/140289.
Since the doctest is actually running itself, we need to handle the output directly inside it.
cc `@fmease`
r? `@notriddle`
here is my small fix
changelog: fix suggestion span to avoid showing macro name in
`.div_ceil()` suggestion
i changed this line
`let divisor_snippet = snippet_with_applicability(cx,
rhs.spansource_callsite(), "..", applicability);`
to this line
`let divisor_snippet = snippet_with_applicability(cx, rhs.span, "..",
applicability);`
to fix problem where this warning in macro expands like this
```rust
4 | let _ = (x + 7) / 8;
| ^^^^^^^^^^^ help: consider using `.div_ceil()`: `x.div_ceil(y!())`
```
[play it
yourself](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=397aa8cd2ffffb24a286fbddbc75446c)
as you can see here it looks like `x.div_ceil(y!())` and contains macro
signature
so i fixed this problem, i will look closely if there any more problems
like this and fix them in order
**Related issue**
fixes
[rust-lang/rust-clippy#14665](https://github.com/rust-lang/rust-clippy/issues/14665)
check types of const param defaults
fixes#139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete
r? `@BoxyUwU`
compiletest: Re-land using the new non-libtest executor by default
This PR re-lands #139998, which had the misfortune of triggering download-rustc in its CI jobs, so we didn't get proper test metrics for comparison with the old implementation. So that was PR was reverted in #140233, with the intention of re-landing it alongside a dummy compiler change to inhibit download-rustc.
---
Original PR description for #139998:
>The new executor was implemented in #139660, but required a manual opt-in. This PR activates the new executor by default, but leaves the old libtest-based executor in place (temporarily) to make reverting easier if something unexpectedly goes horribly wrong.
>
>Currently the new executor can be explicitly disabled by passing the `-N` flag to compiletest (e.g. `./x test ui -- -N`), but eventually that flag will be removed, alongside the removal of the libtest dependency. The flag is mostly there to make manual comparative testing easier if something does go wrong.
>
>As before, there *should* be no user-visible difference between the old executor and the new executor.
---
r? jieyouxu
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.
This updates the lint-docs tool to default to the 2024 edition. The lint
docs are supposed to illustrate the code with the latest edition, and I
just forgot to update this in
https://github.com/rust-lang/rust/pull/133349.
Some docs needed to add the `edition` attribute since they were assuming
a particular edition, but were missing the explicit annotation.
This removes the hard-coded list of edition support in the lint-docs
tool, and instead just assumes the edition attribute is something valid.
There isn't a real reason to have this, as rustc will error if given a
wrong number. This should be easier to maintain going forward.
The def path printer in `get_def_path` essentially calls
`Symbol::intern(&symbol.to_string())` for simple symbols in a path.
This accounts for ~30% of the runtime of get_def_path.
We can avoid this by simply appending the symbol directly when available.
Simply try to unpeel AsyncFnKindHelper goal in `emit_specialized_closure_kind_error`
Tweak the handling of `AsyncFnKindHelper` goals in `emit_specialized_closure_kind_error` to not be so special-casey, and just try to unpeel one or two layers of obligation causes to get to their underlying `AsyncFn*` goal.
Fixes https://github.com/rust-lang/rust/issues/140292
Update wasm-component-ld to 0.5.13
This commit updates the vendored `wasm-component-ld` binary to 0.5.13 which includes some various bug fixes and new feature updates for upcoming component model features coming down the pike. Not expected to break any existing workflows, just a normal update.
transmutability: Support char, NonZeroXxx
Note that `NonZero` support is not wired up, as the author encountered
bugs while attempting this. A future commit will wire up `NonZero`
support.
r? ````@jswrenn````
