Remove unused feature gates
After finding some unused feature gates in rust-lang/rust#143155 , I wrote a small script to see if I can find any others.
And I did. Not a lot, but still a small win 😁
Contains a few instances of `iter_from_coroutine` that can be removed due to rust-lang/rust#142801 (I guess).
`librustdoc` house-keeping 🧹
This PR mostly removes a bunch of crate-level attributes that were added at some point, but then later on became unnecessary:
- some `#[feature]` gates
- some `#[allow]`s
- a `#[recursion_limit]`
Then I went ahead and sprinkled some tidy sorting on the remaining attrs, and `Cargo.toml`.
Trying to give my anal retentiveness some peace of mind 😅
Improve documentation of `TagEncoding`
This PR is follow-up from the [discussion here](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20VariantId.3DDiscriminant.20when.20tag.20is.20niche.20encoded.3F/with/524384295).
It aims at making the `TagEncoding` documentation less ambiguous and more detailed with references to relevant implementation sides. It especially clears up the ambiguous use of discriminant/variant index, which sparked the discussion referenced above.
PS: While working with layout data, I somehow ended up looking at the docs for `FakeBorrowKind` and noticed that the one example was not in a doc comment. I hope that this is minor enough of a fix for it to be okay in this otherwise unrelated PR.
Add regression test for #137857 to ensure that we generate intra doc links for extern crate items.
Fixes https://github.com/rust-lang/rust/issues/137857.
I checked that linking to extern crates was generating valid links (with the `/index.html` part) and since it's already working, just adding a regression test.
r? `@notriddle`
Doc: clarify priority of lint level sources
This updates the rustc book to clearly document how conflicting lint configurations are resolved across different sources, including command-line flags, crate-level attributes, in-line attributes, and `--cap-lints`.
It also explains the special behavior of `forbid` and `force_warn`.
Fixesrust-lang/rust#124088
Update cargo
7 commits in 409fed7dc1553d49cb9a8c0637d12d65571346ce..930b4f62cfcd1f0eabdb30a56d91bf6844b739bf
2025-06-23 15:55:04 +0000 to 2025-06-28 14:58:43 +0000
- Use a different lint for the `fix_only_once_for_duplicates` test (rust-lang/cargo#15713)
- chore: bump to 0.91.0; update changelog (rust-lang/cargo#15710)
- Add `http.proxy-cainfo` config for proxy certs (rust-lang/cargo#15374)
- chore(deps): update msrv (3 versions) to v1.86 (rust-lang/cargo#15709)
- chore(deps): update msrv (1 version) to v1.88 (rust-lang/cargo#15706)
- Rework `cargo-test-support` & `testsuite` to use `CARGO_BIN_EXE_*` for Cargo (rust-lang/cargo#15692)
- fix: Expand error messages around path dependency on `cargo package` and `cargo publish` (rust-lang/cargo#15705)
BTreeSet: remove duplicated code by reusing `from_sorted_iter`
The method `BTreeSet::from_sorted_iter` was introduced in 49ccb7519f55bd117d2ab50b7a030637f380aec6, but it was not consistently used throughout the codebase. As a result, some code redundantly reimplemented its logic. This commit fixes the problem.
Use tidy to sort `sym::*` items
Use tidy to sort the symbols in the invocation of `symbols!`, instead of implementing the ordering check inside the proc macro.
(asked `````@nnethercote````` about this on zulip, he didn't have any reservations about making this change)
This has a couple of benefits:
- tidy's "version sort" (thanks to rust-lang/rust#141311 !) is nicer than the naive-cmp sort, so, e.g. `AtomicI{8, 16, 32, 64, 128}` are properly sorted by bit width.
- consistency with the rest of the repo
- allows us to remove a bit of order-verifying code from the `symbols!` proc macro impl
update internal `send_signal` comment
the vxwork did not have the old comment updated in rust-lang/rust#141990 so update here;
signaling -> sending signals to because the latter reads better to me.
Add windows-gnullvm hosts to the manifest
I made a mistake testing https://github.com/rust-lang/rust/pull/140772 only with `rustup-toolchain-install-master` which doesn't care about the manifests.
This means windows-gnullvm self-hosting will have to wait one more release, unless this change is backported to beta and a new beta release is made, which doesn't seem worth the trouble.
rustdoc: show attributes on enum variants
mostly for #[non_exhaustive]
unsure if there's any attributes we should take care to *not* include, it could use `render_code_attribute` and `is_non_exhaustive` instead, if that is a concern.
fixesrust-lang/rust#142599
Skip unnecessary components in x64 try builds
We unnecessarily rebuild `wasm-component-ld`, `llvm-bitcode-linker` and Cranelift during the intermediate PGO builds several times times, which is unnecessarily and increases the duration of try builds. This PR also disables some unnecessary dist components.
r? `````@jieyouxu`````
Do not include NUL-terminator in computed length
This PR contains just the first commit of rust-lang/rust#142579 which changes it so that the string length stored in the `Location` is the length of the `&str` rather than the length of the `&CStr`. Since most users will want the `&str` length, it seems better to optimize for that use-case.
There should be no visible changes in the behavior or API.
std::net: adding `unix_socket_exclbind` feature for solaris/illumos.
allows to have a tigher control over the binding exclusivness of the socket.
ACP: https://github.com/rust-lang/libs-team/issues/366
Only compute recursive callees once.
Inlining MIR in a cyclic call graph may create query cycles, which are ICEs. The current implementation `mir_callgraph_reachable(inlining_candidate, being_optimized)` checks if calling `inlining_candidate` may cycle back to `being_optimized` that we are currently inlining into.
This PR replaces this device with query `mir_callgraph_cyclic(being_optimized)` which searches the call graph for all cycles going back to `being_optimized`, and returns the set of functions involved in those cycles.
This is a tradeoff:
- in the current implementation, we perform more walks, but shallower;
- in this new implementation, we perform fewer walks, but exhaust the graph.
I'd have liked to compute this using some kind of SCC, but generic parameters make resolution path-dependent, so usual graph algorithms do not apply.
