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
The idea of this option is to allow cargo to use a separate browser from
the rest of the system. My motivation in doing this is that I want to
write a script that adds a symbolic link in some web root on my system
such that I can access my docs via the http protocol to avoid the
limitations of the file protocol that are accessibility problems for me.
For instance, zoom is not retained across multiple pages and Stylus
filters don't work well.
This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.
This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).
Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.
By doing so, rustdoc will also emit workspace-relative filenames for the doctests.
This was first landed in #8954 but later backed out in #8996 because it changed the CWD of rustdoc test invocations.
The second try relies on the new `--test-run-directory` rustdoc option which was added in https://github.com/rust-lang/rust/pull/81264 to explicitly control the rustdoc test cwd.
fixes#8993
When checking the fingerprint for rustdoc and applying
the corresponding logic, we don't only need to consider
the `target/doc` folder (Host target) but also triple targets.
So now the actual compilation targets are checked during the
rustdoc_fingerprint processing and they're treated as the Host/doc
folder.
- Instead of `fs` we use the `utils::paths` functions
to interact with the filesystem.
- The doc fingerprint is now stored under `target/` instead
of `target/doc/`.
- The code in `compile` has been reduced to a single function call.
Once `RustDocFingerprint::check_rustdoc_fingerprint()` is
executed it might happen that the `doc/` dir is removed.
This means that when we call `fingerprint.write()` we need
to create the `doc` directory again.
- Check wether the fingerprint is created with the
correct data after a `rustdoc` execution.
- Check wether the previous docs are removed if the version
used to compile them reported in the fingerprint is different
from the actual one being used by the compiler.
