Allow `true` and `false` as options for `strip` option
This follows the convention of `lto` and `debug` that allow `true` for
the highest level, and `false` for disabled.
Signed-off-by: David Calavera <david.calavera@gmail.com>
This follows the convention of `lto` and `debug` that allow `true` for
the highest level, and `false` for disabled.
Signed-off-by: David Calavera <david.calavera@gmail.com>
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.
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.
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.
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
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
Unstable updates
This is a collection of updates for unstable/nightly feature support, intended to provide better messages for users and better internal and external documentation. Separated by commit, in summary:
* Added comments and new docstrings for improved internal documentation.
* Added new documentation to the reference guide on how unstable things work.
* Also added redirects for stabilized features so any external links won't be broken.
* Add a targeted error message if you put `cargo-features` in the wrong place in `Cargo.toml`.
* Remove `publish-lockfile`. The feature was stabilized without the key in #7026 about 1.5 years ago. Also added "removed" support for features, which prints out a more helpful error message.
* Add help messages about stabilized `-Z` flags (instead of spitting out an unhelpful error message).
* Add help messages about stabilized `cargo-features` features.
* Add more context to the error when using `cargo-features` on stable.
* Unhide nightly CLI flags. I changed my mind on how these should work. I think it is useful to "advertise" the existence of these options on stable. The error message if you try to use it should help guide on what to do.
Closes#9074.
Previously, when something was stabilized, Cargo would spit out a very
unhelpful error message about an unknown -Z flag. This changes it so
that it displays a helpful warning (or error).
Fix some issues with `cargo doc` and the new feature resolver.
This contains two related commits fixing some issues with `cargo doc` and the new feature resolver.
The first commit fixes a panic. The old code was using `UnitFor::new_normal` when computing doc units, but this was wrong. That essentially circumvents the new feature resolver, and breaks determining the correct features to use. I don't remember exactly what I was thinking when I wrote that, other than "rustdoc shouldn't care", but it does matter.
Unfortunately changing that makes collisions worse because it aggravates #6313, so the second commit adds some logic for removing some collisions automatically. Specifically:
- Prefers dependencies for the target over dependencies for the host (such as proc-macros).
- Prefers the "newest" version if it comes from the same source.
There are still plenty of situations where there can be collisions, but I'm uncertain on the best way to handle those.
Fixes#9064
Implement support for rust-version field in project metadata
Needs a bunch more work, but I'd like some early feedback! Remaining work:
- [x] Bikeshedding name (picked `rust-version` here over `msrv` or `min-rust-version`)
- [x] Failing test for local dependency with unsatisfied MSRV
- [x] Requirement cannot be smaller than 1.27
- [x] Requirement cannot be smaller than initial release of edition used
- [x] Check for `run`, `verify` and `publish` subcommands
- [x] More tests (would love feedback on this)
- [x] Handle pre-release identifiers
- [x] Disallow semver range operators
- [x] Feature gate it
- [x] Add documentation for unstable feature
Minimal version of `@moxian's` earlier take in #7801.
cc rust-lang/rust#65262
There are some cases where `cargo doc` will try to document two things
with the same crate_name. This attempts to automatically remove some of
those duplicates based on some rules:
- Prefers dependencies for the target over dependencies for the host
(such as proc-macros).
- Prefers the "newest" version if it comes from the same source.
There are still plenty of situations where there can be collisions, but
I'm uncertain on the best way to handle those.
Cargo's cyclic dependency graph detection turns out to have had a bug
for quite a long time as surfaced by #9073. The bug in Cargo has to do
with how dev-dependencies are handled. Cycles are "allowed" through
dev-dependencies because the dev-dependency can depend on the original
crate. Our cyclic graph detection, however, was too eagerly flagging a
package as known to not have a cycle before we had processed everything
about it.
The fix here was basically to just simplify the graph traversal. Instead
of traversing the raw `Resolve` this instead creates an alternate
in-memory graph which has the actual edges we care about for cycle
detection (e.g. every edge that wasn't induced via a dev-dependency).
With this simplified graph we then apply the exact same algorithm, but
this time it should be less buggy because we're not trying to do funky
things about switching sets about what's visited halfway through a
traversal.
Closes#9073
Sort available binaries when multiple
From:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: basic-tutorial-13, basic-tutorial-6, basic-tutorial-1, basic-tutorial-4, basic-tutorial-9, basic-tutorial-2, basic-tutorial-3, basic-tutorial-5, basic-tutorial-12, playback-tutorial-4, basic-tutorial-8, basic-tutorial-7
```
To:
```
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: basic-tutorial-1, basic-tutorial-12, basic-tutorial-13, basic-tutorial-2, basic-tutorial-3, basic-tutorial-4, basic-tutorial-5, basic-tutorial-6, basic-tutorial-7, basic-tutorial-8, basic-tutorial-9, playback-tutorial-4
```
If a package is tested and the library for the package wasn't built
(e.g. only tested or it wasn't present) then the `links` env vars from
dependencies weren't showing up to the build script by accident. This
was an accidental regression from #8969.
The intention of #8969 was to exclude connections to build scripts
connected via dev-dependencies, but it only applied a heuristic because
the unit graph doesn't retain information about dev-dependencies. The
fix here is to instead actually retain information about
dev-dependencies which is only used for constructing the unit graph and
connecting build script executions to one another.
Closes#9063
Stabilize -Zfeatures and -Zpackage-features.
This follows through with [RFC 2957](https://github.com/rust-lang/rfcs/pull/2957) to stabilize the new feature resolver, and `-Zpackage-features` command-line changes.
This also rewrites the "Features" chapter to try to expand it a little.
I decided to leave the `-Zfeatures` flag in for now for testing, but it can be removed at a later date.
There is a code change related to the `package-name/feature-name` syntax for the `--features` flag. I wanted to stabilize that for `resolver = "1"`, but I previously neglected to separate that behavior out, so it required change to `Workspace::members_with_features` to make that work (see the `resolver1_member_features` test).
Closes#4328Closes#5364Closes#7914Closes#7915Closes#7916Closes#8088Closes#8431
