rustdoc: Erase `#![doc(document_private_items)]`
I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang/rust#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`.
However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang/rust#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang/rust#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted.
Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute.
I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say.
Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks
This PR makes `...` arguments without a pattern in non-foreign functions (such as the argument in `unsafe extern "C" fn f(...) {}`) a future-compatibility warning; making this error would be consistent with how `unsafe extern "C" fn f(u32) {}` is handled. Allowing `...` arguments without a pattern in non-foreign functions is a source of confusion for programmers coming from C, where the `...` parameter is never named and instead calling `va_start` is required; disallowing `...` arguments without a pattern also improves the overall consistency of the Rust language by matching the treatment of other arguments without patterns. `...` arguments without a pattern in `extern` blocks (such as `unsafe extern "C" { fn f(...); }`) continue to compile without warnings after this PR, as they are already stable and heavily used (and don't cause the mentioned confusion as they are just being used in function declarations).
As all the syntax gating for `c_variadic` has been done post-expansion, this is technically a breaking change. In particular, code like this has compiled on stable since Rust 1.35.0:
```rust
#[cfg(any())] // Equivalent to the more recent #[cfg(false)]
unsafe extern "C" fn bar(_: u32, ...) {}
```
Since this is more or less a stability hole and a Crater run shows only the `binrw` crate is using this, I think it would be ok to break this. This will require a lang FCP.
The idea of rejecting `...` pre-expansion was first raised here https://github.com/rust-lang/rust/pull/143546#issuecomment-3043142052.
Tracking issue: rust-lang/rust#44930
cc `@folkertdev` `@workingjubilee`
r? `@joshtriplett`
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to https://github.com/rust-lang/rust/issues/81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
Implement `&pin` patterns and `ref pin` binding modes
Implement `&pin` patterns and `ref pin` binding modes, part of [pin ergonomics](https://github.com/rust-lang/rust/issues/130494).
r? `@Nadrieril`
cc `@traviscross` `@eholk`
stop specializing on `Copy`
fixes https://github.com/rust-lang/rust/issues/132442
`std` specializes on `Copy` to optimize certain library functions such as `clone_from_slice`. This is unsound, however, as the `Copy` implementation may not be always applicable because of lifetime bounds, which specialization does not take into account; the result being that values are copied even though they are not `Copy`. For instance, this code:
```rust
struct SometimesCopy<'a>(&'a Cell<bool>);
impl<'a> Clone for SometimesCopy<'a> {
fn clone(&self) -> Self {
self.0.set(true);
Self(self.0)
}
}
impl Copy for SometimesCopy<'static> {}
let clone_called = Cell::new(false);
// As SometimesCopy<'clone_called> is not 'static, this must run `clone`,
// setting the value to `true`.
let _ = [SometimesCopy(&clone_called)].clone();
assert!(clone_called.get());
```
should not panic, but does ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6be7a48cad849d8bd064491616fdb43c)).
To solve this, this PR introduces a new `unsafe` trait: `TrivialClone`. This trait may be implemented whenever the `Clone` implementation is equivalent to copying the value (so e.g. `fn clone(&self) -> Self { *self }`). Because of lifetime erasure, there is no way for the `Clone` implementation to observe lifetime bounds, meaning that even if the `TrivialClone` has stricter bounds than the `Clone` implementation, its invariant still holds. Therefore, it is sound to specialize on `TrivialClone`.
I've changed all `Copy` specializations in the standard library to specialize on `TrivialClone` instead. Unfortunately, the unsound `#[rustc_unsafe_specialization_marker]` attribute on `Copy` cannot be removed in this PR as `hashbrown` still depends on it. I'll make a PR updating `hashbrown` once this lands.
With `Copy` no longer being considered for specialization, this change alone would result in the standard library optimizations not being applied for user types unaware of `TrivialClone`. To avoid this and restore the optimizations in most cases, I have changed the expansion of `#[derive(Clone)]`: Currently, whenever both `Clone` and `Copy` are derived, the `clone` method performs a copy of the value. With this PR, the derive macro also adds a `TrivialClone` implementation to make this case observable using specialization. I anticipate that most users will use `#[derive(Clone, Copy)]` whenever both are applicable, so most users will still profit from the library optimizations.
Unfortunately, Hyrum's law applies to this PR: there are some popular crates which rely on the precise specialization behaviour of `core` to implement "specialization at home", e.g. [`libAFL`](89cff63702/libafl_bolts/src/tuples.rs (L27-L49)). I have no remorse for breaking such horrible code, but perhaps we should open other, better ways to satisfy their needs – for example by dropping the `'static` bound on `TypeId::of`...
compiletest: Run the `lldb_batchmode.py` script in LLDB's embedded Python
Historically, LLDB debuginfo tests have used a Python script to control LLDB via its Python API, instead of invoking the `lldb` command directly.
Unfortunately, this requires us to find and use a version of Python that is compatible with LLDB's Python bindings.
However, it turns out that there is a simpler way to find a compatible Python interpreter: use the one that is embedded in LLDB itself, via the `script` command.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#148248 (Constify `ControlFlow` methods without unstable bounds)
- rust-lang/rust#148285 (Constify `ControlFlow` methods with unstable bounds)
- rust-lang/rust#148510 (compiletest: Do the known-directives check only once, and improve its error message)
- rust-lang/rust#148655 (Fix invalid macro tag generation for keywords which can be followed by values)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Do the known-directives check only once, and improve its error message
This PR is a combination of three changes:
- Store the list of known directives in a set, so that checking a directive name doesn't require a linear scan
- Extract the known-directives check out of `iter_directives` and do it only once, instead of multiple times per file
- Improve the error message for unknown directives, [as requested on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Compiletest.20directive.20parsing.20error/with/553598083)
The change to error messages is fused with the extraction, since doing it independently would have been more awkward.
---
## Before
```text
Testing stage1 with compiletest suite=coverage mode=coverage-map (aarch64-apple-darwin)
errors encountered during EarlyProps parsing: /Users/stuart/Dev/rust/rust/tests/coverage/trivial.rs
2025-11-05T01:55:46.440012Z ERROR compiletest::directives: /Users/stuart/Dev/rust/rust/tests/coverage/trivial.rs:2: detected unknown compiletest test directive `add-core-stubs`
thread '<unnamed>' (36268582) panicked at src/tools/compiletest/src/directives.rs:72:13:
errors encountered during EarlyProps parsing
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
## After
```text
Testing stage1 with compiletest suite=coverage mode=coverage-map (aarch64-apple-darwin)
thread '<unnamed>' (36270772) panicked at src/tools/compiletest/src/lib.rs:876:9:
directives check failed:
ERROR: unknown compiletest directive `add-core-stubs` at /Users/stuart/Dev/rust/rust/tests/coverage/trivial.rs:2
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Constify `ControlFlow` methods with unstable bounds
Feature: `const_control_flow`
Tracking issue: rust-lang/rust#148739
This PR constifies the methods on `ControlFlow` with a dependency on rust-lang/rust#143874.
Constify `ControlFlow` methods without unstable bounds
Feature: `min_const_control_flow`
Tracking issue: rust-lang/rust#148738
This PR constifies some of the methods on `ControlFlow`.
Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2
Implement the [MCP 932](https://github.com/rust-lang/compiler-team/issues/932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.
Closesrust-lang/rust#148353.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
r? jieyouxu
cc `@davidtwco` `@Noratrieb`
Implement IsZero for ().
Implement default `IsZero` for all arrays, only returning true if the array is empty
(making the existing array impl for `IsZero` elements a specialization).
Optimize `IsZero::is_zero` for arrays of zero-sized `IsZero` elements.
Fix typo in unstable-book link
This prevented the links from being rendered. Sorry for not noticing this before my changes were merged yesterday.
Introduced in https://github.com/rust-lang/rust/pull/147935
cc ``@petrochenkov``
tidy: Don't bypass stderr output capture in unit tests
In unit tests, writes to stderr that don't use `eprint!` or `eprintln!` will not be captured, and instead interfere with test harness output, making it unreadable.
<details>
<summary><b>Detailed before/after</b></summary>
## Before
```text
$ x test tidyselftest --no-doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
Finished `release` profile [optimized + debuginfo] target(s) in 0.23s
Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)
running 20 tests
tidy [alphabetical-test]: bad:3 found `tidy-alphabetical-start` expecting `tidy-alphabetical-end`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad: reached end of file expecting `tidy-alphabetical-end`tidy [alphabetical-test]: bad:4: line not in alphabetical order
tidy [alphabetical-test]: bad:5 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test].: tidy [alphabetical-test...bad:4: line not in alphabetical order..]: tidy [alphabetical-test]: ..
bad:7: line not in alphabetical order
tidy [tidy [bad:2 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
alphabetical-testtidy [tidy [alphabetical-test]: bad:4: line not in alphabetical order
.tidy [alphabetical-test]..]alphabetical-testtidy []: bad:4: line not in alphabetical orderalphabetical-testalphabetical-test]: tidy [FAILalphabetical-test
]: FAIL
]: FAIL
: FAIL
: bad:4: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [.alphabetical-test]: FAIL
.tidy [alphabetical-test]: FAIL
..tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
.....
test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.01ms
Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 26.88µs
finished in 0.255 seconds
Build completed successfully in 0:00:00
```
## After
```text
$ x test tidyselftest --no-doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
Finished `release` profile [optimized + debuginfo] target(s) in 1.74s
Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)
running 20 tests
....................
test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.35ms
Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 27.17µs
finished in 1.764 seconds
Build completed successfully in 0:00:02
```
</details>
bootstrap: Render doctest timing reports as text, not JSON
These doctest timing reports were added to libtest/rustdoc in https://github.com/rust-lang/rust/pull/144909, but bootstrap's custom test-output renderer wasn't taught about them, so they were being printed as raw JSON instead.
Before:
```text
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
```
After:
```text
all doctests ran in 0.73s; merged doctests compilation took 0.72s
```
<details>
<summary><b>Detailed before/after in context</b></summary>
## Before
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.28ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 403.67µs
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
finished in 1.505 seconds
Build completed successfully in 0:00:01
```
## After
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.12ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 395.67µs
all doctests ran in 0.73s; merged doctests compilation took 0.72s
finished in 1.493 seconds
Build completed successfully in 0:00:01
```
</details>
mgca: Finish implementation of `#[type_const]`
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#140729fixesrust-lang/rust#140860
- **Fix `#[type_const]` attribute placement validation**
- **Perform WF-checking on type_const RHS's**
- **Check type_const type is ConstParamTy_ and that RHS matches it**
- **Check that impls of `#[type_const]` consts also have the attr**
r? ```@BoxyUwU```
fix: disable self-contained linker when bootstrap-override-lld is set
Part of rust-lang/rust#148708.
Makes `rust.bootstrap-override-lld` set to `true` or `"external"` disable self-contained linker — actually using linker from one's system.
Remove `#[const_trait]`
Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute.
r? ```@rust-lang/project-const-traits```
