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````
[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 |
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).
rustdoc-json: Move `#[macro_export]` from `Other` to it's own variant
Followup to rust-lang/rust#142936.
cargo-semver-checks [cares about this attribute](4a0d1b0ca1/src/visibility_tracker.rs (L459-L476)), and it wasn't included in the initial PR for structured attributes CC `@obi1kenobi.`
r? `@GuillaumeGomez`
Extend `is_case_difference` to handle digit-letter confusables
This PR extends `is_case_difference` to handle digit-letter confusables
Add support for detecting 0/O, 1/l, 5/S, 8/B, 9/g confusables in error suggestions.
r? `@estebank`
Simplify library dependencies on `compiler-builtins`
The three panic-related library crates need to have access to `core`, and `compiler-builtins` needs to be in the crate graph. Rather than specifying both dependencies, switch these crates to use `rustc-std-workspace-core` which already does this.
This means there is now a single place that the `compiler-builtins` dependency needs to get configured, for everything other than `alloc` and `std`.
The second commit removes `compiler-builtins` from `std` (more details in the message).
The three panic-related library crates need to have access to `core`,
and `compiler-builtins` needs to be in the crate graph. Rather than
specifying both dependencies, switch these crates to use
`rustc-std-workspace-core` which already does this.
This means there is now a single place that the `compiler-builtins`
dependency needs to get configured, for everything other than `alloc`
and `std`.
Deduplicate `IntTy`/`UintTy`/`FloatTy`.
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This commit removes them and places a single definition in `rustc_ast_ir`. This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but means a bunch of silly conversion functions can be removed.
r? `@fmease`
Uniform `enter_trace_span!` and add documentation
1. The latest changes to `enter_trace_span!` were ported from Miri (see https://github.com/rust-lang/miri/pull/4452#discussion_r2204958019), so now both the `rustc_const_eval` and the Miri macro accept the same syntax. Furthermore, the Miri macro was changed to just call rustc_const_eval`'s, to avoid duplication.
2. I made the `layout_of` (& friends) calls use that new syntax, e.g. `enter_trace_span!(layouting::layout_of, ...)`
3. I made sure the macro specifies all types/traits/macros it refers to using `$crate::`, so the macro works anywhere independently of which types/traits/macros are imported in the context it is used in.
4. I added documentation, examples and tips to the macro's doc. To make the rustdoc compile I had to add some hidden lines (`#`), but now it acts as a compilation test which will avoid reintroducing issue 3. in the future. I will also create a documentation file with everything one needs to know about tracing at a later point, but I figured adding some of that info directly on the tracing macro makes it more discoverable.
5. In `stack.rs` I made it so that the `"frame"` span has a field named "frame" (instead of "message") with the data about the frame. This field used to be called "message" (tracing's default) since it was previously formatted using `"{}", instance`, and now I replaced it with `frame = %instance`.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#136840 (Fix linker-plugin-lto only doing thin lto)
- rust-lang/rust#144053 (Remove install Rust script from CI)
- rust-lang/rust#144297 (Make `libtest::ERROR_EXIT_CODE` const public to not redefine it in rustdoc)
- rust-lang/rust#144721 (`std_detect`: Linux 6.16 support for RISC-V)
r? `@ghost`
`@rustbot` modify labels: rollup
Make `libtest::ERROR_EXIT_CODE` const public to not redefine it in rustdoc
I think it's better to make this constant public so it can be used by crates using `libtest` as dependency.
As a side-note, I will update https://github.com/rust-lang/rust/pull/143900 to make use of this constant once this is current PR is merged.
Fix linker-plugin-lto only doing thin lto
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
560149b5e3/clang/lib/CodeGen/BackendUtil.cpp (L1150)
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
e258bca950/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp (L4441-L4446)
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
This commit changes it to store a `Region` instead of a `RegionVid` for the `Var` cases:
- We avoid having to call `Region::new_var` to re-create `Region`s from
`RegionVid`s in a few places, avoiding the interning process, giving a
small perf win. (At the cost of the type allowing some invalid
combinations of values.)
- All the cases now store two `Region`s, so the commit also separates
the `ConstraintKind` (a new type) from the `sub` and `sup` arguments
in `Constraint`.
There are identical definitions in `rustc_type_ir` and `rustc_ast`. This
commit removes them and places a single definition in `rustc_ast_ir`.
This requires adding `rust_span` as a dependency of `rustc_ast_ir`, but
means a bunch of silly conversion functions can be removed.
The one annoying wrinkle is that the old version had differences in
their `Debug` impls, e.g. one printed `u32` while the other printed
`U32`. Some compiler error messages rely on the former (yuk), and some
clippy output depends on the latter. So the commit also changes clippy
to not rely on `Debug` and just implement what it needs itself.
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
560149b5e3/clang/lib/CodeGen/BackendUtil.cpp (L1150)
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
e258bca950/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp (L4441-L4446)
