This helps me understand the structure of the code a lot.
If any of these are actually reachable, we can put the old code back,
add a new test case, and we will have improved our test coverage.
Update safety comment for new_unchecked in niche_types
Change the safety comment on `new_unchecked` to mention the valid range instead of 0. I noticed this while working on https://github.com/model-checking/verify-rust-std
Properly pass path to staged `rustc` to `compiletest` self-tests
Otherwise, this can do weird things like use a global rustc, or try to use stage 0 rustc. This must be properly configured, because `compiletest` is intended to only support one compiler target spec JSON format (of the in-tree compiler).
Historically, this was probably done so before `bootstrap` was really its own thing, and `compiletest` had to be runnable as a much more "self-standing" tool.
Follow-up to rust-lang/rust#144675, as I didn't realize this until Zalathar pointed it out in [#t-infra/bootstrap > Building vs testing `compiletest` @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Building.20vs.20testing.20.60compiletest.60/near/532040838).
r? ````@Kobzol````
[test][AIX] ignore extern_weak linkage test
The AIX linkage model doesn't support ELF-style extern_weak semantics, so just skip this test, like other platforms that don't have it.
Improve formatting of doc code blocks
We don't currently apply automatic formatting to doc comment code blocks. As a
result, it has built up various idiosyncracies, which make such automatic
formatting difficult. Some of those idiosyncracies also make things harder for
human readers or other tools.
This PR makes a few improvements to doc code formatting, in the hopes of making
future automatic formatting easier, as well as in many cases providing net
readability improvements.
I would suggest reading each commit separately, as each commit contains one
class of changes.
update fortanix tests
Firstly, as far as I can tell, no CI job actually runs any of the fortanix tests? Maybe I'm missing the job that runs these tests though?
In any case, the `assembly` tests now use `minicore`, meaning that they will run regardless of the host architecture (specifically, they will run during a standard PR CI build).
The run-make test is actually broken, and I'd propose to make it just `cargo build` rather than `cargo run`. We can have a separate test for actually running the program, if desired.
Also this test is subject to https://github.com/rust-lang/rust/issues/128733, so I'd like to re-evaluate what parts of the C/C++ compilation are actually required or useful.
cc [``@jethrogb](https://github.com/jethrogb)`` [``@raoulstrackx](https://github.com/raoulstrackx)`` [``@aditijannu](https://github.com/aditijannu)``
r? ``@jieyouxu``
Document guarantees of poisoning
This mostly documents the current behavior of `Mutex` and `RwLock` (rust-lang/rust#143471) as imperfect. It's unlikely that the situation improves significantly in the future, and even if it does, the rules will probably be more complicated than "poisoning is completely reliable", so this is a conservative guarantee.
We also explicitly specify that `OnceLock` never poisons, even though it has an API similar to mutexes.
Fixesrust-lang/rust#143471 by improving documentation.
r? ``@Amanieu``
[rustdoc] Display unsafe attrs with edition 2024 `unsafe()` wrappers.
Use Rust 2024 edition representation for unsafe attributes in rustdoc HTML:
- `#[no_mangle]` -> `#[unsafe(no_mangle)]`
- `#[export_name = "foo"]` -> `#[unsafe(export_name = "foo")]`
- `#[link_section = ".text"]` -> `#[unsafe(link_section = ".text")]`
The 2024 edition representation is used regardless of the crate's own edition. This ensures that Rustaceans don't have to learn the rules of an outdated edition (e.g. that `unsafe()` wasn't always necessary) in order to understand a crate's documentation.
After some looking through the `T-rustdoc` issues, I was not able to find an existing issue for this. Apologies if I missed it.
r? ``````@aDotInTheVoid``````
get rid of some false negatives in rustdoc::broken_intra_doc_links
rustdoc will not try to do intra-doc linking if the "path" of a link looks too much like a "real url".
however, only inline links (`[text](url)`) can actually contain a url, other types of links (reference links, shortcut links) contain a *reference* which is later resolved to an actual url.
the "path" in this case cannot be a url, and therefore it should not be skipped due to looking like a url.
fixes https://github.com/rust-lang/rust/issues/54191
to minimize the number of false positives that will be introduced, the following heuristic is used:
If there's no backticks, be lenient revert to old behavior.
This is to prevent churn by linting on stuff that isn't meant to be a link.
only shortcut links have simple enough syntax that they
are likely to be written accidentlly, collapsed and reference links
need 4 metachars, and reference links will not usually use
backticks in the reference name.
therefore, only shortcut syntax gets the lenient behavior.
here's a truth table for how link kinds that cannot be urls are handled:
| | is shortcut link | not shortcut link |
|--------------|--------------------|-------------------|
| has backtick | never ignore | never ignore |
| no backtick | ignore if url-like | never ignore |
Detect more `cfg`d out items in resolution errors
Use a visitor to collect *all* items (including those nested) that were stripped behind a `cfg` condition.
```
error[E0425]: cannot find function `f` in this scope
--> $DIR/nested-cfg-attrs.rs:4:13
|
LL | fn main() { f() }
| ^ not found in this scope
|
note: found an item that was configured out
--> $DIR/nested-cfg-attrs.rs:2:4
|
LL | fn f() {}
| ^
note: the item is gated here
--> $DIR/nested-cfg-attrs.rs:1:35
|
LL | #[cfg_attr(all(), cfg_attr(all(), cfg(FALSE)))]
| ^^^^^^^^^^
```
```
error[E0433]: failed to resolve: could not find `doesnt_exist` in `inner`
--> $DIR/diagnostics-cross-crate.rs:18:23
|
LL | cfged_out::inner::doesnt_exist::hello();
| ^^^^^^^^^^^^ could not find `doesnt_exist` in `inner`
|
note: found an item that was configured out
--> $DIR/auxiliary/cfged_out.rs:6:13
|
LL | #[cfg(false)]
| ----- the item is gated here
LL | pub mod doesnt_exist {
| ^^^^^^^^^^^^
```
Use a visitor to collect *all* items (including those nested) that were stripped behind a `cfg` condition.
```
error[E0425]: cannot find function `f` in this scope
--> $DIR/nested-cfg-attrs.rs:4:13
|
LL | fn main() { f() }
| ^ not found in this scope
|
note: found an item that was configured out
--> $DIR/nested-cfg-attrs.rs:2:4
|
LL | fn f() {}
| ^
note: the item is gated here
--> $DIR/nested-cfg-attrs.rs:1:35
|
LL | #[cfg_attr(all(), cfg_attr(all(), cfg(FALSE)))]
| ^^^^^^^^^^
```
Remove the witness type from coroutine *args* (without actually removing the type)
This does as much of rust-lang/rust#144157 as we can without having to break rust-lang/rust#143545 and/or introduce some better way of handling higher ranked assumptions.
Namely, it:
* Stalls coroutines based off of the *coroutine* type rather than the witness type.
* Reworks the dtorck constraint hack to not rely on the witness type.
* Removes the witness type from the args of the coroutine, eagerly creating the type for nested obligations when needed (auto/clone impls).
I'll experiment with actually removing the witness type in a follow-up.
r? lcnr
Update cargo
3 commits in a7fcef21feb4d835d1fee83b3f93b4aef86d5545..840b83a10fb0e039a83f4d70ad032892c287570a
2025-07-13 02:25:52 +0000 to 2025-07-30 13:59:19 +0000
- chore: fix some minor issues in comments (rust-lang/cargo#15787)
- feat(schema): Expose `IndexPackage`, the description of a package within a Registry Index (rust-lang/cargo#15770)
- chore: update toml/toml_edit to latest (rust-lang/cargo#15779)
r? ghost
Otherwise, this can do weird things like use a global rustc, or try to
use stage 0 rustc. This must be properly configured, because
`compiletest` is intended to only support one compiler target spec JSON
format (of the in-tree compiler).
add unsupported_calling_conventions to lint list
Seems like you can emit lints without them being on the list, but users cannot control them then... *oops*.
Add tracing to step.rs and friends
Adds tracing calls to functions in `step.rs` (01717ffecfd47eb51f4877da6ad867b329a1ddd5), to friend functions related to evaluation and stepping (cbfa7c4b96b2ea26c1db185da9b59506bf8c8e55), and adds a new trait method `EnteredTraceSpan::or_if_tracing_disabled` (f0d0d1f5ecdf174696c8a74a5bc98967a2751c93).
Adding `EnteredTraceSpan::or_if_tracing_disabled` is optional and is only useful to avoid having both `tracing::info!()` calls (that existed before) and `enter_trace_span!()` calls (that this PR adds) that would be redundant and would slow down the collection of traces. I say it is optional because it adds some cognitive complexity around `EnteredTraceSpan`, which is possibly not worth the reduced redundancy. Let me know if I should revert that commit.
The tracing calls added in this PR are meant to make it easier to understand what was being executing at a particular point when looking at a trace. But they are likely not useful for the purpose of understanding which components are fast/slow, hence why I used `tracing_separate_thread` for them. After opening a trace generated using the code in this PR in https://ui.perfetto.dev, and after executing the following query and then pressing on "Show debug track", you will see something like the following image in the timeline:
```sql
select slices.id, ts, dur, track_id, category, args.string_value as name, depth, stack_id, parent_stack_id, parent_id, slices.arg_set_id, thread_ts, thread_instruction_count, thread_instruction_delta, cat, slice_id from slices inner join args USING (arg_set_id) where args.key = "args." || slices.name and name = "step"
```
<img width="739" height="87" alt="image" src="https://github.com/user-attachments/assets/74ad9619-9a1f-40e5-9ef4-3db31e33d6e1" />
Make tier 3 musl targets link dynamically by default
Since we don't build std for these and don't provide any support for them, these can trivially be changed to link dynamically by default.
