In 12914 we stabilized pkgid spec as unique package identifier for
`cargo metadata`. However, we forgot to make the same change to
JSON message format[^1]. This PR does so.
Note that the `package_id` field in JSON message is not clearly stated
as "opaque", so it might be considered as a breaking change to some extent.
[^1]: https://doc.rust-lang.org/nightly/cargo/reference/external-tools.html#compiler-messages
I've wanted something like this myself. I dislike using `--open`
because I tend to move up to re-run my `cargo doc` run but then have to
edit it to remove `--open`.
Also makes it annoying when opening docs when `cargo doc` is wrapped by
a tool like `make`.
This was previously attempted in #5592:
- Unlike the request in #5562, this aligns with #5592 in always printing
rather than using a flag as this seems generally useful
- Unlike #5592, this prints as an alternative to "Opening" to keep
things light
- Unlike #5592, this prints afterwards as the link is only valid then
Fixes#5562
This stabilizes and enables the `-Z doctest-in-workspace` flag by default.
Also adds another testcase to make sure that the `include!()` and `file!()` macros interact well together.
When documenting private items in a binary, ignore warnings about links to private items
Previously, rustdoc would warn about linking to private items in a binary, even
though cargo unconditionally documents private items in a binary.
This changes cargo to silence the warning, since it's only relevant in
cases where the private items might not be documented.
Fixes https://github.com/rust-lang/rust/issues/89600.
Previously, rustdoc would warn about linking to items in a binary, even
though cargo unconditionally documents private items in a binary.
This changes cargo to silence the warning, since it's only relevant in
cases where the private items might not be documented.
Don't emit "executable" JSON field for non-executables.
The "executable" field of JSON artifact messages was accidentally filled (with the path to `index.html`) when documenting a binary target. This fixes it so that it is null.
Closes#10149
* Docscrape unit not having dev-dependencies included
* Sources for reverse-dependencies generated to the wrong directory
* Incorrect features being selected for Docscrape units
* Panics from Docscrape-dependent packages not being available
Fix `BorrowMutError` when calling `cargo doc --open`
~~I'm not sure why the existing test suite didn't catch this, it definitely calls `cargo doc --open`.~~
I had
```toml
[doc.extern-map]
std = "local"
```
in my `.cargo/config.toml`. Will write a test case that sets that and then tries to run `cargo doc --open`.
Closes#9530
