Update lint-docs to default to Rust 2024
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 also includes a commit to simplify the edition handling in lint-docs.
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`
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 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.
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````
Rollup of 8 pull requests
Successful merges:
- #139865 (Stabilize proc_macro::Span::{start,end,line,column}.)
- #140086 (If creating a temporary directory fails with permission denied then retry with backoff)
- #140216 (Document that "extern blocks must be unsafe" in Rust 2024)
- #140253 (Add XtensaAsmPrinter)
- #140272 (Improve error message for `||` (or) in let chains)
- #140305 (Track per-obligation recursion depth only if there is inference in the new solver)
- #140306 (handle specialization in the new trait solver)
- #140308 (stall generator witness obligations: add regression test)
r? `@ghost`
`@rustbot` modify labels: rollup
Track per-obligation recursion depth only if there is inference in the new solver
Track how many times an obligation has been processed in the fulfillment context by reusing its recursion depth, and only overflow if a singular (root) goal hits the limit.
This also fixes a (probably theoretical at this point) problem where we don't detect pseudo-hangs across `select_where_possible` calls.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/186
r? lcnr
Improve error message for `||` (or) in let chains
**Description**
This PR improves the error message when using `||` in an if let chain expression, addressing #140263.
**Changes**
1. Creates a dedicated error message specifically for `||` usage in let chains
2. Points the primary span directly at the `||` operator
3. Removes confusing secondary notes about "let statements" and unsupported contexts
5. Adds UI tests verifying the new error message and valid cases
**Before**
```rust
error: expected expression, found let statement
--> src/main.rs:2:8
|
2 | if let true = true || false {}
| ^^^^^^^^^^^^^^^
|
= note: only supported directly in conditions of if and while expressions
note: || operators are not supported in let chain expressions
--> src/main.rs:2:24
|
2 | if let true = true || false {}
|
```
**After**
```rust
error: `||` operators are not supported in let chain conditions
--> src/main.rs:2:24
|
2 | if let true = true || false {}
| ^^
```
**Implementation details**
1. Added new `OrInLetChain` diagnostic in errors.rs
2. Modified `CondChecker` in expr.rs to prioritize the `||` error
3. Updated fluent message definitions to use clearer wording
**Related issue**
Fixes#140263
cc ```@ehuss``` (issue author)
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
If creating a temporary directory fails with permission denied then retry with backoff
On Windows, if creating a temporary directory fails with permission denied then use a retry/backoff loop. This hopefully fixes a recuring error in our CI.
cc ```@jieyouxu,``` https://github.com/rust-lang/rust/issues/133959
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.
[compiletest] Parallelize test discovery
Certain filesystems are slow to service individual read requests, but can service many in parallel. This change brings down the time to run a single cached test on one of those filesystems from 40s to about 8s.
In the AST the "then" block is represented as a `Block`. In HIR the
"then" block is represented as an `Expr` that happens to always be.
`ExprKind::Block`. By deconstructing the `ExprKind::Block` to extract
the block within, things print properly.
For `issue-82392.rs`, note that we no longer print a type after the
"then" block. This is good, it now matches how we don't print a type for
the "else" block. (Well, we do print a type after the "else" block, but
it's for the whole if/else.)
Also tighten up some of the pattern matching -- these block expressions
within if/else will never have labels.
