This allows LTO to work when compiling jemalloc, which should yield a
small performance boost, and makes miri's behaviour here match clippy
and rustdoc.
feat: Enable annotate-snippets' simd feature
`annotate-snippets` `simd` feature enables the use of `memchr` when searching for `char`/`str`. This should hopefully improve performance when [`annotate-snippets` is passed large `source`](https://github.com/rust-lang/rust/pull/148188#issuecomment-3550280300).
Bump compiler dependencies
https://github.com/rust-lang/rust/pull/145849#issuecomment-3394832713
This manually downgrades the `wasip`/`wit-bindgen`/`getrandom` deps to avoid pulling in a binary blob, but it would be good to pin this automatically in a way which doesn't cause these blobs to be pulled in.
rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution
Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index` (because it was defined in a different crate), you could only look it up it `Crate::paths`. But there, you don't get the full information, only an `ItemSummary`. This tells you the `path` and the `crate_id`.
But knowing the `crate_id` isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a `ExternalCrate` (via `Crate::external_crates`). But that only tells you the `name` (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features [^1] [^2].
This was originally proposed to be solved via `@LukeMathWalker's` `--orchestrator-id` proposal (https://github.com/rust-lang/compiler-team/issues/635). But that requires invasive changes to cargo/rustc. This PR instead implements `@Urgau's` proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, `cargo rustdoc --message-format=json --output-format=json -Zunstable-options`).
(Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing `Id`s between rustdoc-json document), but that's a future concern)
For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ
CC `@obi1kenobi` (who wants this for cargo-semver-checks [^3]), `@epage` (who's conversations on what and wasn't possible with cargo informed taking this approach to solve this problem)
r? `@GuillaumeGomez`
## TODO:
- [x] Docs: [Done](e4cdd0c24a..457ed4edb1)
- [x] Tests: [Done](2e1b954dc5..4d00c1a7ee)
[^1]: https://github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[^2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
[^3]: https://github.com/obi1kenobi/cargo-semver-checks/issues/638
Update memchr to 2.7.6
memchr 2.7.6 contains a bugfix for aarch64_be.
Note: I'm not sure about how dependency updates are managed in rust.git. If something should go through another branch or will happen automatically, please let me know.
Update cc-rs to 1.2.39
For my purposes, contains fixes when compiling the Rust compiler for Arm64EC.
Checked the commits since 1.2.16, and I don't see anything else that may affect Rust?
`find-msvc-tools` was also factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of the Rust compiler).
It's common to import dependencies from the sysroot via `extern crate`
rather than use an explicit cargo dependency, when it's necessary to use
the same dependency version as used by rustc itself. However, this is
dangerous for crates.io crates, since rustc may not pull in the
dependency on some targets, or may pull in multiple versions. In both
cases, the `extern crate` fails to resolve.
To address this, re-export all such dependencies from the appropriate
`rustc_*` crates, and use this alias from crates which would otherwise
need to use `extern crate`.
collect-license-metadata: Print a diff of the expected output
Previously, `x test collect-license-metadata` gave the following message on errors:
```
gathering license information from REUSE (this might take a minute...)
finished gathering the license information from REUSE in 78.69s
loading existing license information
The existing /home/runner/work/ferrocene/ferrocene/license-metadata.json
file is out of date.
Run ./x run collect-license-metadata to update it.
Error: The existing
/home/runner/work/ferrocene/ferrocene/license-metadata.json file doesn't
match what REUSE reports.
Bootstrap failed while executing `test collect-license-metadata`
```
Notable, this doesn't actually say what went wrong. Print a diff in addition so it's more clear what broke:
```
...
"license": {
"copyright": [
+ "2010 The Rust Project Developers",
"2016, 2017, 2018, 2019, 2020, 2021 AXE Consultants. All Rights",
+ "License. Subject to the terms and conditions of this",
"Notice",
- "The Ferrocene Developers"
+ "The Ferrocene Developers",
+ "[yyyy] [name of copyright owner]"
],
...
```
Currently, this prints the entire text of the JSON file as context. That's not ideal, but it's rare for this to fail, so I think it's ok for now.
I considered using `assert_json_diff` instead of `similar`, but its errors are a lot harder to read IMO, even though they are better at omitting unnecessary context:
```
Diff: json atoms at path ".files.children[0].children[10].license.copyright[0]" are not equal:
lhs:
"2016 The Fuchsia Authors"
rhs:
"2019 The Crossbeam Project Developers"
json atoms at path ".files.children[0].children[10].license.spdx" are not equal:
lhs:
"BSD-2-Clause AND (Apache-2.0 OR MIT)"
rhs:
"Apache-2.0 OR MIT"
json atom at path ".files.children[0].children[10].children" is missing from lhs
json atoms at path ".files.children[0].children[10].name" are not equal:
lhs:
"library/std/src/sys/sync/mutex/fuchsia.rs"
rhs:
"library/std/src/sync/mpmc"
...
```
Previously, `x test collect-license-metadata` gave the following message
on errors:
```
gathering license information from REUSE (this might take a minute...)
finished gathering the license information from REUSE in 78.69s
loading existing license information
The existing /home/runner/work/ferrocene/ferrocene/license-metadata.json
file is out of date.
Run ./x run collect-license-metadata to update it.
Error: The existing
/home/runner/work/ferrocene/ferrocene/license-metadata.json file doesn't
match what REUSE reports.
Bootstrap failed while executing `test collect-license-metadata`
```
Notable, this doesn't actually say what went wrong.
Print a diff in addition so it's more clear what broke:
```
...
"license": {
"copyright": [
+ "2010 The Rust Project Developers",
"2016, 2017, 2018, 2019, 2020, 2021 AXE Consultants. All Rights",
+ "License. Subject to the terms and conditions of this",
"Notice",
- "The Ferrocene Developers"
+ "The Ferrocene Developers",
+ "[yyyy] [name of copyright owner]"
],
...
```
Currently, this prints the entire text of the JSON file as context.
That's not ideal, but it's rare for this to fail, so I think it's ok for
now.
I considered using `assert_json_diff` instead of `similar`, but its
errors are a lot harder to read IMO, even though they are better at
omitting unnecessary context:
```
Diff: json atoms at path ".files.children[0].children[10].license.copyright[0]" are not equal:
lhs:
"2016 The Fuchsia Authors"
rhs:
"2019 The Crossbeam Project Developers"
json atoms at path ".files.children[0].children[10].license.spdx" are not equal:
lhs:
"BSD-2-Clause AND (Apache-2.0 OR MIT)"
rhs:
"Apache-2.0 OR MIT"
json atom at path ".files.children[0].children[10].children" is missing from lhs
json atoms at path ".files.children[0].children[10].name" are not equal:
lhs:
"library/std/src/sys/sync/mutex/fuchsia.rs"
rhs:
"library/std/src/sync/mpmc"
...
```
This patch changes `bump-stage0` to include:
* The sha256 hash of the channel manifest used to create `src/stage0`.
* The rust and rustfmt git commit in `src/stage0`.
* Hashes of all the artifacts, like the source tarball, in `src/stage0`.
Combined this will allow for:
* Projects that bootstrap their own compiler, such as Fuchsia, or users
of [bootstrap], to build their compilers offline without needing to
communicate with static.rust-lang.org.
* Auditors to detect if the channel manifest, and all the artifacts
inside the manifest, were modified after it was used to generate
`src/stage0`. Furthermore, if they did find modified artifacts, they
could determine if the Rust Signing Key was compromised by checking if
any modified file was signed properly.
Finally, it allows regeneration of `src/stage0` when specifying both the
day of the build for rust, and the day of the build for rustfmt, which
can allow a maintainer to regenerate `src/stage0` to verify nothing
changed.
[bootstrap]: https://github.com/dtolnay/bootstrap
[mrustc]: https://github.com/thepowersgang/mrustc
[win] Use find-msvc-tools instead of cc to find the linker and rc on Windows
`find-msvc-tools` was factored out from `cc` to allow updating the use in `rustc_codegen_ssa` (finding the linker when running the Rust compiler) and `rustc_windows_rc` (finding the Windows Resource Compiler when running the Rust compiler) to be separate from the use in `rustc_llvm` (building LLVM as part of building the Rust compiler).
test: Use SVG for terminal url test
I came across the test for `-Zterminal-urls` and found its output a bit hard to read. So, I decided to switch it to an SVG test, as I found it easier to differentiate the link and link text.
Note: `anstyle-svg` needed to be upgraded to at least `0.1.8` to support links in SVGs, so I went ahead and upgraded it to the latest version (`0.1.11`).
