Prior to this commit `cargo metadata` would not emit the value of a
target's "doc" setting, used by `cargo doc` to determine whether
documentation should be generated. However, this information is useful
for machine programs interested in such targets, and the information is
already made available on the internal representation of a target, so
this commit just exposes that during target serialization for emit.
cf https://github.com/deadlinks/cargo-deadlinks/issues/99
This commit is targeted at further improving the error messages
generated from git errors. For authentication errors the actual URL
fetched is now printed out as well if it's different from the original
URL. This should help handle `insteadOf` logic where SSH urls are used
instead of HTTPS urls and users can know to track that down.
Otherwise the logic about recommending `net.git-fetch-with-cli` was
tweaked a bit and moved to the same location as the rest of our error
reporting.
Note that a change piggy-backed here as well is that `Caused by:` errors
are now automatically all tabbed over a bit instead of only having the
first line tabbed over. This required a good number of tests to be
updated, but it's just an updated in renderings.
Some tools can support rust doctests (e.g. highlighting
or launching). So it should be possible to find out if
doctests are enabled for a target or not. This commit
adds `doctest` field to `cargo metadata` output.
This commit fixes an issue when pipelining mode is used in handling
recompilations. Previously a sequence of compilations could look like:
* Crate A starts to build
* Crate A produces metadata
* Crate B, which depends on A, starts
* Crate B finishes
* Crate A finishes
In this case the mtime for B is before that of A, which fooled Cargo
into thinking that B needed to be recompiled. In this case, however, B
doesn't actually need to be recompiled because it only depends on the
metadata of A, not the final artifacts.
This unfortunately resulted in some duplication in a few places, but not
really much moreso than already exists between fingerprinting and compilation.
If an error occurs while compiling a metabuild target with
`--message-format=json`, it would panic because it was unable to serialize
`Target`. This change makes it so that it places a fake "metabuild.rs" string in
the `src_path` in this situation.
I'm very unhappy with this solution, but I'm unable to think of something
better. Changing `src_path` to an `Option` (or something) would break existing
tools. I tried implementing something that resets the `src_path` to the correct
path in the target dir after the workspace is configured, but it felt very
brittle – you have to fix up after all dependencies are downloaded, and there's
not a good way to ensure that happens correctly.
This adds a `with_json_contains_unordered` to help with tests.
cargo's extra verbose mode is useful for getting detailed information out of
builds in CI where it can be difficult to examine the build environment
after-the-fact. However, when multiple build scripts are running as part of a
build it's not always clear what output is from which build script. This patch
makes cargo prefix each line of build script output with the crate name and
version this case.
- Use new enum `TargertSourcePath` for Target::src_path to make it explicit that metabuild has a special path.
- `cargo metadata` now skips the metabuild Target.
- JSON artifacts include the true path to the metabuild source file. This may not be the best solution, but it's unclear what it should be, and I would prefer to avoid breaking the output. Alternatively it could just not emit anything? I'm not completely familiar with the use case of these artifact messages.
- Place the file in `target/.metabuild/metabuild-pkgname-HASH.rs` instead of in the debug/release directory. Its contents do not depend on the profile.
- Fix bug in write_if_changed.
- More tests.
