The `exec_with_output` function and subsequent writing to stdout and
stderr is replaced with the `exec` function that inherits the stdio
streams from Cargo is used.
Weirdly, I originally tried to use the `exec` function but I go no
output. The `cargo run -- rustc --print cfg` appear to just hang. So, I
switched to using the `exec_with_output` function. Now, the `exec`
function appears to work and it is much simplier. There must have been
something else going on with my system at the time.
The `TargetInfo` type, but more specifically the `TargetInfo::new`
method is used instead of the making the `env_args` function public and
using it.
This means the `env_args` function can go back to being private, too.
The `output_err_info` function can be private now that the
implementation for the `cargo rustc --print <FOO>` command has changed
to not capture the output.
Change git dependencies to use `HEAD` by default
This commit follows through with work started in #8522 to change the
default behavior of `git` dependencies where if not branch/tag/etc is
listed then `HEAD` is used instead of the `master` branch. This involves
also changing the default lock file format, now including a `version`
marker at the top of the file notably as well as changing the encoding
of `branch=master` directives in `Cargo.toml`.
If we did all our work correctly then this will be a seamless change.
First released on stable in 1.47.0 (2020-10-08) Cargo has been emitting
warnings about situations which may break in the future. This means that
if you don't specify `branch = 'master'` but your HEAD branch isn't
`master`, you've been getting a warning. Similarly if your dependency
graph used both `branch = 'master'` as well as specifying nothing, you
were receiving warnings as well. These two situations are broken by this
commit, but it's hoped that by giving enough times with warnings we
don't actually break anyone in practice.
Only printing an empty line after the first target output is changed to
use the `enumerate` method on an Iterator with a non-zero index.
I could not get the `drop_println` macro to compile. Something about the
`shell` missing. The standard library `println` macro seems work fine.
Fix panic with doc collision orphan.
As I feared, the collision removal added in #9077 caused problems due to orphans left in the unit graph. Ironically, it was the collision warning detection code which failed, as it iterates over all the keys of the graph.
The solution is to remove all orphans from the graph after collisions have been removed.
Fixes#9136
This commit fixes a bug in Cargo where after `DefaultBranch` and
`Branch("master")` are considered distinct no v2 lockfile would by
default match a dependency specification with the `branch = 'master'`
annotation. A feature of the v2 lockfile, however, is that no mention of
a branch is equivalent to the `master` branch.
The bug here is fixed by updating the code which registers a previous
lock file with our `PackageRegistry`. This code registers nodes, only
with v2 lock files, for both default and `master` branch git
dependencies. This way requests for either one will get matched now that
they're considered distinct.
This commit follows through with work started in #8522 to change the
default behavior of `git` dependencies where if not branch/tag/etc is
listed then `HEAD` is used instead of the `master` branch. This involves
also changing the default lock file format, now including a `version`
marker at the top of the file notably as well as changing the encoding
of `branch=master` directives in `Cargo.toml`.
If we did all our work correctly then this will be a seamless change.
First released on stable in 1.47.0 (2020-10-08) Cargo has been emitting
warnings about situations which may break in the future. This means that
if you don't specify `branch = 'master'` but your HEAD branch isn't
`master`, you've been getting a warning. Similarly if your dependency
graph used both `branch = 'master'` as well as specifying nothing, you
were receiving warnings as well. These two situations are broken by this
commit, but it's hoped that by giving enough times with warnings we
don't actually break anyone in practice.
Fix permission issue with `cargo vendor`.
I think there was an unintended regression in #8937 where the vendored output does not retain the original permissions.
Fixes#9127.
Add split-debuginfo profile option
This commit adds a new `split-debuginfo` option to Cargo compilation
profiles which gets forwarded to the `-Csplit-debuginfo` codegen option
in rustc. This commit also sets the default, only on macOS, to be
`-Csplit-debuginfo=unpacked`. The purpose of this change is to leverage
rust-lang/rust#79570 to avoid running `dsymutil` on incremental builds
while also preserving a pleasant debugging experience by default. This
should lead to much faster incremental build times on macOS since
`dsymutil` isn't exactly the speediest tool in the world.
This is technically a breaking change in Cargo because we're no longer
by-default producing the `*.dSYM` folders on macOS. If those are still
desired, however, authors can always run `dsymutil` themselves or
otherwise configure `split-debuginfo = 'packed'` in their
manifest/profile configuration.
Add RegistryBuilder for tests, and update crates-io error handling.
This adds `RegistryBuilder` to the test suite to make it more flexible to create different registry setups, and to reuse code a little more easily.
This also makes a small adjustment to the registry API to add a `ResponseError` type to make it easier to work with API errors. As part of this, some tests were added to validate the API behavior for response errors. There are only a few very small changes here:
* Extra newlines are removed from the headers printed in the error message.
* The UTF-8 error now also includes the text "invalid response from server".
* The "file too large" crates.io publish error now displays the tarball size. (There is no test for this because it is only issued for talking to `crates.io`.)
Split from #9111.
Fix env/cfg set for `cargo test` and `cargo run`.
There are some situations where a build script may need to run multiple times for the same package during the same `cargo` session. There was a bug in that some of the values in the `Compilation` struct didn't handle this case. The solution here is to be more careful about how this extra data is associated with `Unit`s, instead of assuming a package's build script only runs once.
The things that were not being handled properly:
* `Compilation::extra_env`, which is the output of `cargo:rustc-env` in build scripts. The solution here is to use the `Metadata` hash which is used elsewhere for distinguishing build script outputs.
* `Compilation::cfgs`, which is the output of `cargo:rustc-cfg` in build scripts and the features to be set, and this is only used for doctests. The solution here is to just add those `--cfg` flags directly in the `Doctest` struct.
The situations that cause a build script to be run multiple times:
* A package needed for both the host and target. In the test here, this was accomplished with a proc-macro (which has to be `host`) and a cyclical dev dependency, but there are many other ways to trigger this.
* Something built with different features (with the new feature resolver), usually due to host/target differences.
* Something built with different profile settings, usually due to host/target differences.
Fixes#9100
This commit updates the rustc info cache to cache failures to execute
rustc as well as successes. This fixes a weird issue where if you're
probing for flags the `rustc_info_cache` test fails on channels which
don't have the flag since previously a failure to execute rustc resulted
in never caching the result.
This commit adds a new `split-debuginfo` option to Cargo compilation
profiles which gets forwarded to the `-Csplit-debuginfo` codegen option
in rustc. This commit also sets the default, only on macOS, to be
`-Csplit-debuginfo=unpacked`. The purpose of this change is to leverage
rust-lang/rust#79570 to avoid running `dsymutil` on incremental builds
while also preserving a pleasant debugging experience by default. This
should lead to much faster incremental build times on macOS since
`dsymutil` isn't exactly the speediest tool in the world.
This is technically a breaking change in Cargo because we're no longer
by-default producing the `*.dSYM` folders on macOS. If those are still
desired, however, authors can always run `dsymutil` themselves or
otherwise configure `split-debuginfo = 'packed'` in their
manifest/profile configuration.
Impl warn for locked install without Cargo.lock
If we're installing in --locked mode and there's no `Cargo.lock` published
ie. the bin was published before https://github.com/rust-lang/cargo/pull/7026
the cargo install errors were not stating that it was due to the lack of
the `Cargo.lock` file. Instead, the error seemed completely unrelated.
Therefore, this tries to address this by adding a warn in the stderr
output.
Closes#9106
I will need some help on the testing side (assuming the code I added for the warning is correct).
It looks to me that the publish function implemented for testing purposes does not publish `Cargo.lock` which is the actual convention. Should this be updated too? See #7026
Document -Z extra-link-arg.
Whilst reading the cargo source code, I encountered `-Z extra-link-arg`. I'd missed this flag before because it is not documented in `-Z help`.
This commit adds the one-liner documentation.
([This argument **is** mentioned in the unstable cargo book](https://doc.rust-lang.org/beta/cargo/reference/unstable.html#extra-link-arg))
Flip 'foo' and 'bar' to be consistent
The "Renaming dependencies" section initially uses 'foo' as the crate name and 'bar' as a rename, but then swaps them and uses 'bar' as the example crate name in the context of optional dependencies. Now both examples in this section treat 'foo' as the original crate name.
The "Renaming dependencies" section initially uses 'foo' as the crate name and 'bar' as a rename, but then swaps them and uses 'bar' as the example crate name in the context of optional dependencies. Now both examples in this section treat 'foo' as the original crate name.
Don't try to parse MSRV if feature is not enabled
`@ehuss` is something like this what you had in mind? Should we add tests to make sure this works correctly?
