Fix error message for calling a non-tuple struct
This feels a bit odd checking for `"0"` but I can't see how else to check for it being a Tuple
closes https://github.com/rust-lang/rust/issues/148919
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](https://github.com/rust-lang/rust/compare/e4cdd0c24a994fed354081b5f907680a11f2ddc5..457ed4edb184997d5d6f879c6a220bc4d69ff6fd)
- [x] Tests: [Done](https://github.com/rust-lang/rust/compare/2e1b954dc52bf7e5a6e9311394df760db37d383f..4d00c1a7ee5e03d1e78801cc01a85dac08ab603b)
[^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
add `rust.rustflags` and per target `rustflags` options to `bootstrap.toml`
Part of rust-lang/rust#148782; see also rust-lang/rust#148708
Add new options `rust.rustflags` for all targets and `rustflags` par target that will pass specified flags to rustc for all stages. Target specific flags override (are passed after) global `rust.rustflags` ones.
This makes easy to persistently pass any flag to the compiler when building rustc. For example you can use a different linker by putting the following in `bootstrap.toml`:
```toml
[rust]
rustflags = ["-Clinker=clang", "-Clink-arg=--ld-path=wild"]
```
r? bootstrap
Allow unnormalized types in drop elaboration
I work on a [rustc driver](https://github.com/AeneasVerif/charon) that aims to extract the full polymorphic MIR of a crate. Currently the one thing I can't get is drop glue because it fails on unnormalizable types like the fields of `Cow` or `NonZero`.
This PR removes the one check for unnormalized types in drop elaboration. It's a `span_delay_bug` so only there to help catch mistakes. I think that's fine to remove? If something downstream relies on types being normalized the right approach is for MIR validation to check for normalized types, not that one random check.
compiletest: Use JSON "binary-format" to decide `//@ only-elf` and `//@ ignore-elf`
Some tests only apply to ELF targets, or want to enable different test revisions for ELF and non-ELF targets. So compiletest supports the `//@ only-elf` and `//@ ignore-elf` directives to make that possible.
Historically, deciding whether the current target is an ELF target relied on a handful of ad-hoc string comparisons against the target tuple.
However, nowadays compiletest has access to the output of `--print=all-target-specs-json`, and that JSON output specifies the binary format of each target, making it much easier to determine whether a target is ELF or not.
flush_delayed: add note about stashed diagnostics
r? `@nnethercote`
Is `emit_stashed_diagnostics` the right advice to give? The other option seems to be to call `finish_diagnostics`. That's what I ended up doing (for now) in https://github.com/rust-lang/miri/pull/4702 because it best matches what happens during normal compilation.
Guillaume Gomez