[rustdoc] Fix `--show-coverage` when JSON output format is used
I realized while looking on the docs.rs page of the `sysinfo` crate that the coverage numbers displayed were wrong:
I realized that it was because `--show-coverage --output-format=json` was relying on the same logic as the JSON output for the doc generation whereas it should not. I fixed it by changing the API for querying `is_json` a bit.
The underlying issue is that JSON output format is stripping reexports of items from private modules.
r? ``@notriddle``
add rustc std workspace crate sources
This adds the sources for the crates listed at https://crates.io/search?q=rustc-std-workspace in this repo. The first commit adds the original sources as downloaded from crates.io (with `Cargo.toml.orig` moved back over `Cargo.toml`), and adds a README explaining what this is about. The 2nd commit updates the sources to make the core and alloc crates re-exports of the "actual" core and alloc crates, as was already the case with `std`, and also adds a `repository` link to the manifest so one can figure out where to find these crates.
I bumped the version for the core and alloc crates in the hope that the new versions can be published on crates.io shortly after this PR lands.
See [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/rustc-std-workspace-core.20crate.20is.20empty) for a bit more context.
r? `@Amanieu`
Call the target libdir target libdir
Because it's the target libdir.
`--print` uses the same terminology, and it's a simple way to make it obviously different from `$sysroot/lib`.
Do not format generic consts
We introduced **nightly support** for generic const items in #113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items.
r? `````@calebcartwright````` or `````@ytmimi`````
Subtree sync for rustc_codegen_cranelift
The highlight this time is an update to Cranelift 0.113,
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
get rid of a whole bunch of unnecessary rustc_const_unstable attributes
In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.
So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.
Add `--print host-tuple` to print host target tuple
People often parse `-vV` output to get to the host tuple, which is annoying to do. It's easier to just get it directly.
I called it "host-tuple" instead of "host" because it's clearer that it's just the target name. I'm open to different names, but I think this one is fine.
a quick GitHub search for `'^host` reveals many instances of people doing the parsing, for example:
68e0ca57cd/README.md (L369)0e38473b0c/main.sh (L96)8a3553b865/README.md (L625)43f3ec3970/do.sh (L35)
needs a compiler FCP. I could also do an MCP but I think just an FCP here makes the most sense.
miri: Directly use rustc_abi
I tried to make this a PR to the miri repo for funsies. Ironically, the integration flow meant that it would use a too-old toolchain hash, and I didn't understand the build system there enough to want to manually fiddle with the hashes.
rustdoc: skip stability inheritance for some item kinds
For some item kinds it's incorrect to inherit their parent's stability, because they might be accessible without referring to the parent directly -- This PR removes the stability inheritance for these items and reverts their displayed stability to that before https://github.com/rust-lang/rust/pull/130798.
Impl items, both inherent and trait impls, have a stability, but it is ignored when checking for enabled features. However, impl items are automatically unstable if they're nested inside an unstable module -- this caused the children of impl to inherit the instability and lead to https://github.com/rust-lang/rust/issues/132440.
Furthermore, for associated items only the stability of the associated item itself is checked and not that of its parent impl. This is true even for trait impls and we have [relied on this behavior in the standard library in the past](https://doc.rust-lang.org/1.37.0/std/slice/trait.SliceConcatExt.html#tymethod.concat), so these also shouldn't inherit the impl's stability.
I've also removed the stability inheritance for primitives and keywords so that viewing e.g. [the `i32` docs on `core`](https://doc.rust-lang.org/nightly/core/primitive.i32.html) will no longer show "since 1.6.0". Note that we currently don't annotate stability for the keyword docs, but if we start doing so in the future then this is probably more correct.
fixes (after backport) https://github.com/rust-lang/rust/issues/132440
Update cargo
18 commits in e75214ea4936d2f2c909a71a1237042cc0e14b07..0310497822a7a673a330a5dd068b7aaa579a265e
2024-10-25 16:34:32 +0000 to 2024-11-01 19:27:56 +0000
- Add more metadata to `rustc_fingerprint` (rust-lang/cargo#14761)
- test(rustfix): switch to a simpler case for dedup-suggestions (rust-lang/cargo#14765)
- chore(deps): update rust crate security-framework to v3 (rust-lang/cargo#14766)
- chore(deps): update rust crate gix to 0.67.0 (rust-lang/cargo#14762)
- fix(util): Respect all `..`s in `normalize_path` (rust-lang/cargo#14750)
- test(doc): Resolve flaky test (rust-lang/cargo#14760)
- refactor(test): Remove dead 'expect_stdout_contains_n' check (rust-lang/cargo#14759)
- add unstable -Zroot-dir flag to configure the path from which rustc should be invoked (rust-lang/cargo#14752)
- docs(resolver): Further v3 prep (rust-lang/cargo#14753)
- fix: track version in fingerprint dep-info files (rust-lang/cargo#14751)
- test: Remove unused msrv-policy (rust-lang/cargo#14748)
- download targeted transitive deps of with artifact deps' target platform (rust-lang/cargo#14723)
- Remove requirement for --target when invoking Cargo with -Zbuild-std (rust-lang/cargo#14317)
- docs(fingerprint): document the encoding of Cargo's depinfo (rust-lang/cargo#14745)
- Allow build scripts to report error messages through `cargo::error` (rust-lang/cargo#14743)
- fix(publish): Downgrade version-exists error to warning on dry-run (rust-lang/cargo#14742)
- fix: clean up for deprecated and removed commands (rust-lang/cargo#14739)
- Deprecate `cargo verify-project` (rust-lang/cargo#14736)
rustdoc: Directly use rustc_abi instead of reexports
rustc_target reexports a lot of things that are in rustc_abi, but that will be over soon and now is probably a good time to switch. Uses of rustc_target remain where they inquire about the target tuple.
Remove support for `-Zprofile` (gcov-style coverage instrumentation)
Tracking issue: #42524
MCP: https://github.com/rust-lang/compiler-team/issues/798
---
This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.
(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)
Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
- #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
rustc_target reexports a lot of things that are in rustc_abi, but
that will be over soon and now is probably a good time to switch.
Uses of rustc_target remain where they inquire about the target tuple.
