Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built
without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether
the compiler's LLVM was built with zstd support. But the compiler itself
already knows whether LLVM has zstd or not, so it's easier for compiletest to
just ask the compiler.
rustdoc: make mergeable crate info more usable
Part of https://github.com/rust-lang/rust/issues/130676
Adds documentation and a feature change aimed at making this usable without breaking backwards compat.
cc ``@EtomicBomb``
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
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://www.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
[1]: https://www.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
This is useful when you have two dependencies that use different trait for
the same thing and with the same name. The user can accidentally implement
the bad one which might be confusing. This commits refactorizes existing
diagnostics about multiple different crates with the same version and adds
a note when similarly named traits are found. All diagnostics are merged
into a single one.
Adds missing test coverage for rustdoc's `--test-builder` option.
The existing test only covered the error case (non-executable builder). This PR
adds:
- A custom test builder that logs arguments and forwards to rustc
- A test verifying that `--test-builder` successfully invokes the custom
builder with rustc-style arguments
- Improved comments explaining both the error and success test scenarios
The test validates that custom builders can properly intercept and handle
doctest compilation.
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
rustdoc: Use configured target modifiers when collecting doctests
To support loading dependencies with target modifiers and avoid ABI mismatch errors.
Fixesrust-lang/rust#146465.
This test suffers from multiple issues that make it very, very difficult
to fix, and even if fixed, it would still be too fragile.
For some background context, this test tries to check that the
optimization introduced in [PR-78122] is not regressed. The optimization
is for eliding `usize` formatting machinery and padding code from the
final binary.
Previously, writing any `fmt::Arguments` would cause the `usize`
formatting and padding machinery to be included in the final binary
since indexing used in `fmt::write` generates code using
`panic_bounds_check` (that prints the index and length). Those bounds
check are never hit, since `fmt::Arguments` never contain any
out-of-bounds indicies.
The `Makefile` version of `fmt-write-bloat` was ported to the present
`rmake.rs` test infra in [PR-128147]. However, this PR just tries to
maintain the original test logic.
The original test, it turns out, already have multiple limitations:
- It only runs on non-Windows, since the `no_std` test of the original
version tries to link against a `libc`. [PR-128807] worked around this
by using a substitute name. We re-enabled this test in [PR-142841],
but it turns out the assertions are too weak, it will even vacuously
pass for no symbols at all.
- In [PR-143669], we tried to make this test more robust by comparing
the set of expected versus unexpected panic-related symbols, subject
to if std was built with debug assertions.
However, in working on [PR-143669], we've come to realize that this test
is fundamentally very fragile:
- The set of panic symbols depend on whether the standard library was
built with or without debug assertions.
- Different platforms often have different sets of panic
machinery modules, functions and paths, and thus different sets of
panic symbols. For instance, x86_64 msvc and i686 msvc have different
panic codepaths.
- This comes back to the way the test is trying to gauge the absence of
panic symbols -- it tries to look for symbol substring matches for
"known" panic symbols. This is fundamentally fragile, because the test
is trying to peek into the symbols of the resultant binary
post-linking, based on fuzzy matches (the symbols are mangled as
well).
Based on this assessment, we determined that we should remove this test.
This is not intended to exclude the possibility of reintroducing a more
robust version of this test. For instance, we could consider some kind
of more controllable post-link "end product" integration codegen test
suite.
[PR-78122]: https://github.com/rust-lang/rust/pull/78122
[PR-128147]: https://github.com/rust-lang/rust/pull/128147
[PR-128807]: https://github.com/rust-lang/rust/pull/128807
[PR-142841]: https://github.com/rust-lang/rust/pull/142841
[PR-143669]: https://github.com/rust-lang/rust/pull/143669
rustdoc: Rename unstable option `--nocapture` to `--no-capture` in accordance with `libtest`
Context: https://github.com/rust-lang/rust/issues/133073, https://github.com/rust-lang/rust/pull/139224 (TL;DR: `libtest` has soft-deprecated `--nocapture` in favor a new & stable `--no-capture`; we should follow suit).
Since the rustdoc flag is unstable (tracking issue: https://github.com/rust-lang/rust/issues/148116), we're allowed to remove the old flag immediately. However since the flag has existed for 4 years we could hard-deprecate the flag first or at least be considerate and provide a diagnostic referring users to the new flag. This PR does neither. Let me know what you would think would be best.
Cargo doesn't use this flag, not yet at least (https://github.com/rust-lang/cargo/pull/9705), so we really are free to sunset this flag without bigger consequences.
This fixes a limitation that prevented me from adding it to Cargo.
The rust compiler-docs bundle is built by running multiple `cargo`
commands in succession, and I want to support that, so I'm stuck
putting the doc parts all in one directory, so that subsequent
`cargo` runs can pick up the previous runs' data. It's less clean,
but it should still be usable in hermetic build environments if
you give every crate its own directory (which you needed to do
before, oddly enough).
This option hasn't done anything for a long time, and can be
removed. I've kept a shim in place to avoid breaking docs.rs,
but the option no longer does anything.
Using git-blame, I tracked this option down to
f77ebd4ffa, the commit that
introduced EmitType in the first place. It was used with
SharedResource::Unversioned, which no longer exists since
f9e1f6ffdf removed them.
CC https://github.com/rust-lang/rust/pull/146220
Part of https://github.com/rust-lang/rust/issues/83784
The issue cannot be reproduced with the former testcase of creating external crates because
rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标"
because it is not a valid indentifier (starts with number, and contain non ascii chars)
But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases
So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.
feat(rustdoc): `--emit=depinfo` output to stdout via `-`
rustdoc's `--emit=depinfo` flag now supports using `-` to write the output to stdout,
aligning with rustc's behavior.
This will fix <https://github.com/rust-lang/rust/issues/147649>.
### How to review
* The first commit demonstrates that `rustdoc --emit=depinfo=-` hasn't yet supported emitting to stdout.
* The second implements it and the diff shows how the behavior changes.
Move computation of allocator shim contents to cg_ssa
In the future this should make it easier to use weak symbols for the allocator shim on platforms that properly support weak symbols. And it would allow reusing the allocator shim code for handling default implementations of the upcoming externally implementable items feature on platforms that don't properly support weak symbols.
In addition to make this possible, the alloc error handler is now handled in a way such that it is possible to avoid using the allocator shim when liballoc is compiled without `no_global_oom_handling` if you use `#[alloc_error_handler]`. Previously this was only possible if you avoided liballoc entirely or compiled it with `no_global_oom_handling`. You still need to avoid libstd and to define the symbol that indicates that avoiding the allocator shim is unstable.
Currently it is possible to avoid linking the allocator shim when
__rust_no_alloc_shim_is_unstable_v2 is defined when linking rlibs
directly as some build systems need. However this requires liballoc to
be compiled with --cfg no_global_oom_handling, which places huge
restrictions on what functions you can call and makes it impossible to
use libstd. Or alternatively you have to define
__rust_alloc_error_handler and (when using libstd)
__rust_alloc_error_handler_should_panic
using #[rustc_std_internal_symbol]. With this commit you can either use
libstd and define __rust_alloc_error_handler_should_panic or not use
libstd and use #[alloc_error_handler] instead. Both options are still
unstable though.
Eventually the alloc_error_handler may either be removed entirely
(though the PR for that has been stale for years now) or we may start
using weak symbols for it instead. For the latter case this commit is a
prerequisite anyway.
compiler: Hint at multiple crate versions if trait impl is for wrong ADT
If a user does e.g.
impl From<Bar> for foo::Foo
and get a compilation error about that `From<Bar>` is not implemented for `Foo`, check if multiple versions of the crate with `Foo` is present in the dependency graph. If so, give a hint about it.
Note that a test is added as a separate commit so it is easy to see what effect the fix has on the emitted error message.
This can be seen as a continuation of rust-lang/rust#124944.
I think this closes RUST-71693 but I haven't checked since it lacks a minimal reproducer. If this gets merged I'll ask that reporter if this fix works for them.
## Real world example
I encountered this case in the wild and didn't realize I had multiple versions of a crate in my dependency graph. So I was a bit confused at first. For reference, here is what that looked like.
<details>
<summary>Click to expand</summary>
### Before fix
```
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:5
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:48
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `auto-merge-dependabot-pull-requests-webhook` (bin "auto-merge-dependabot-pull-requests-webhook") due to 2 previous errors
```
### After fix
```
Compiling auto-merge-dependabot-pull-requests-webhook v0.1.0 (/home/martin/src/auto-merge-dependabot-prs/rust-webhook)
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:5
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
help: item with same name found
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_runtime-0.13.0/src/diagnostic.rs:43:1
|
43 | pub struct Diagnostic {
| ^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate `lambda_runtime` are being used?
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
error[E0277]: the trait bound `lambda_http::lambda_runtime::Diagnostic: From<Error>` is not satisfied
--> src/main.rs:73:48
|
73 | lambda_http::run(service_fn(handle_event)).await
| ^^^^^ the trait `From<Error>` is not implemented for `lambda_http::lambda_runtime::Diagnostic`
|
help: item with same name found
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_runtime-0.13.0/src/diagnostic.rs:43:1
|
43 | pub struct Diagnostic {
| ^^^^^^^^^^^^^^^^^^^^^
= note: perhaps two different versions of crate `lambda_runtime` are being used?
= help: the following other types implement trait `From<T>`:
`lambda_http::lambda_runtime::Diagnostic` implements `From<&str>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError + Send + Sync>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Box<dyn StdError>>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<Infallible>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<lambda_runtime::deserializer::DeserializeError>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::io::Error>`
`lambda_http::lambda_runtime::Diagnostic` implements `From<std::string::String>`
= note: required for `Error` to implement `Into<lambda_http::lambda_runtime::Diagnostic>`
note: required by a bound in `lambda_http::run`
--> /home/martin/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/lambda_http-0.17.0/src/lib.rs:199:26
|
194 | pub async fn run<'a, R, S, E>(handler: S) -> Result<(), Error>
| --- required by a bound in this function
...
199 | E: std::fmt::Debug + Into<Diagnostic>,
| ^^^^^^^^^^^^^^^^ required by this bound in `run`
For more information about this error, try `rustc --explain E0277`.
error: could not compile `auto-merge-dependabot-pull-requests-webhook` (bin "auto-merge-dependabot-pull-requests-webhook") due to 2 previous errors
```
</details>
try-job: dist-various-1
try-job: aarch64-msvc-1
If a user does e.g.
impl From<Bar> for foo::Foo
and get a compilation error about that `From<Bar>` is not implemented
for `Foo`, check if multiple versions of the crate with `Foo` is present
in the dependency graph. If so, give a hint about it.
I encountered this case in the wild and didn't realize I had multiple
versions of a crate in my dependency graph. So I was a bit confused at
first. This fix will make life easier for others.
Fix doctest output json
Fixesrust-lang/rust#144798.
Hopefully it will work with the new changes in `libtest` without needing to do both at once.
This PR moves the `rustdoc` merged doctest extra information directly into `libtest` to ensure they share the same rendering to prevent the bug uncovered in rust-lang/rust#144798.
cc `@lolbinary` (as you reviewed the first PR)
And since we're making changes to `libtest`:
r? `@Amanieu`
Fix backtraces with `-C panic=abort` on linux; emit unwind tables by default
The linux backtrace unwinder relies on unwind tables to work properly, and generating and printing a backtrace is done by for example the default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see history below) so that backtraces work.
Closes https://github.com/rust-lang/rust/issues/81902 which is **regression-from-stable-to-stable**
Closes https://github.com/rust-lang/rust/issues/94815
### History
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C panic=abort` (see https://github.com/rust-lang/rust/pull/45031 and https://github.com/rust-lang/rust/issues/81902#issuecomment-3046487084).
In 1.45 a workaround in the form of `-C force-unwind-tables=yes` was added (see https://github.com/rust-lang/rust/pull/69984).
`-C panic=abort` was added in [Rust 1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable) and the motivation was binary size and compile time. But given how confusing that behavior has turned out to be, it is better to make binary size optimization opt-in with `-C force-unwind-tables=no` rather than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other tricks that can be used that has a higher impact.
# Release Note Entry Draft:
## Compatibility Notes
* [Fix backtraces with `-C panic=abort` on Linux by generating unwind tables by default](https://github.com/rust-lang/rust/pull/143613). Build with `-C force-unwind-tables=no` to keep omitting unwind tables.
try-job: aarch64-apple
try-job: armhf-gnu
try-job: aarch64-msvc-1
The linux backtrace unwinder relies on unwind tables to work properly,
and generating and printing a backtrace is done by for example the
default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see
history below) so that backtraces work.
History
=======
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in
Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C
panic=abort` (see 24cc38e3b0).
In 1.45 (see cda994633e) a workaround in the form
of `-C force-unwind-tables=yes` was added.
`-C panic=abort` was added in [Rust
1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable)
and the motivation was binary size and compile time. But given how
confusing that behavior has turned out to be, it is better to make
binary size optimization opt-in with `-C force-unwind-tables=no` rather
than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other
tricks that can be used that has a higher impact.
debuginfo: add an unstable flag to write split DWARF to an explicit directory
Bazel requires knowledge of outputs from actions at analysis time, including file or directory name. In order to work around the lack of predictable output name for dwo files, we group the dwo files in a subdirectory of --out-dir as a post-processing step before returning control to bazel. Unfortunately some debugging workflows rely on directly opening the dwo file rather than loading the merged dwp file, and our trick of moving the files breaks those users. We can't just hardlink the file or copy it, because with remote build execution we wouldn't end up with the un-moved file copied back to the developer's workstation. As a fix, we add this unstable flag that causes dwo files to be written to a build-system-controllable location, which then lets bazel hoover up the dwo files, but the objects also have the correct path for the dwo files.
r? `@davidtwco`
