Optimize lock file format for git merge conflicts
This commit is an attempt to refine Cargo's lock file format to generate
less git merge conflicts for lock file updates as well as make it easier
to manage lock file updates. The new lock file format has a few major changes:
* The `[metadata]` table is no longer used to track checksums. The
packages themselves now list `checksum` fields directly.
* The entries in the `dependencies` key no longer unconditionally
mention the version/source of the dependency. When unambiguous only
the name or only the name/version are mentioned.
As mentioned before the goal here is to reduce git merge conflict
likelihood between two cargo updates to a lock file. By not using
`[metadata]` the updates to package checksums should only happen on the
package itself, not in a shared metadata table where it's easy to
conflict with other updates. Additionally by making `dependencies`
entries shorter it's hoped that updating a crate will only either add
entries to a lock file or update lines related to just that package.
It's theorized that the amount of updates necessary to a lock file are
far less than today where the version has to be updated in many
locations.
As with all lock file format changes this new format is not turned on by
default. Support is added so Cargo will preserve it if it sees it (and
tests are added too), and then some time down the road we can flip the
switch and turn this on by default.
Force clippy to run.
This causes `cargo clippy-preview` to always run, instead of possibly emitting no output if it is run a second time.
This is just a personal preference of mine, but I think would be better behavior which we have talked about before. I don't think the arguments that it should be "fast" like `cargo check` apply here. Once [cache-messages](https://github.com/rust-lang/cargo/issues/6986) is stabilized, this can be removed.
This commit is an attempt to refine Cargo's lock file format to generate
less git merge conflicts for lock file updates as well as make it easier
to manage lock file updates. The new lock file format has a few major changes:
* The `[metadata]` table is no longer used to track checksums. The
packages themselves now list `checksum` fields directly.
* The entries in the `dependencies` key no longer unconditionally
mention the version/source of the dependency. When unambiguous only
the name or only the name/version are mentioned.
As mentioned before the goal here is to reduce git merge conflict
likelihood between two cargo updates to a lock file. By not using
`[metadata]` the updates to package checksums should only happen on the
package itself, not in a shared metadata table where it's easy to
conflict with other updates. Additionally by making `dependencies`
entries shorter it's hoped that updating a crate will only either add
entries to a lock file or update lines related to just that package.
It's theorized that the amount of updates necessary to a lock file are
far less than today where the version has to be updated in many
locations.
As with all lock file format changes this new format is not turned on by
default. Support is added so Cargo will preserve it if it sees it (and
tests are added too), and then some time down the road we can flip the
switch and turn this on by default.
Optimize runtime of `#[cargo_test_macro]`
I've noticed recently that the incremental compile time for our test
suite has felt like it's increased quite a bit. I think one reason is
that everything has to go through `#[cargo_test_macro]` unconditionally
on all incremental builds, and wow do we have a lot of tests being
pumped through that macro.
Instrumenting the macro a little bit shows that we spend nearly 2.5
seconds on each compilation simply executing this macro (note that it's
in debug mode as well, not release since we typically don't execute
tests in release mode.
This commit instead drops the usage of `syn` and `quote` in favor of a
"raw procedural macro" which is much more optimized for just our use
case, even in debug mode. This drops the collective time spent in the
macro to 0.2 seconds, even in debug mode!
I've noticed recently that the incremental compile time for our test
suite has felt like it's increased quite a bit. I think one reason is
that everything has to go through `#[cargo_test_macro]` unconditionally
on all incremental builds, and wow do we have a lot of tests being
pumped through that macro.
Instrumenting the macro a little bit shows that we spend nearly 2.5
seconds on each compilation simply executing this macro (note that it's
in debug mode as well, not release since we typically don't execute
tests in release mode.
This commit instead drops the usage of `syn` and `quote` in favor of a
"raw procedural macro" which is much more optimized for just our use
case, even in debug mode. This drops the collective time spent in the
macro to 0.2 seconds, even in debug mode!
Don't fail if we can't acquire readonly lock
This commit updates support from #6940 to not only gracefully handle
situations where the lock can be acquired in readonly but not read/write
mode but also handle situations where even a readonly lock can't be
acquired. If a readonly lock can't be acquired (and the read/write
failed) then we likely can't touch anything in the directory, so there's
no value gained from locking anyway.
Closes#7147
This commit updates support from #6940 to not only gracefully handle
situations where the lock can be acquired in readonly but not read/write
mode but also handle situations where even a readonly lock can't be
acquired. If a readonly lock can't be acquired (and the read/write
failed) then we likely can't touch anything in the directory, so there's
no value gained from locking anyway.
Closes#7147
Add support for multiple --features options
Closes#7076
Pretty straightforward, but I added an extra test to make sure that space-separated features work in conjunction with multiple --features options.
Add a way to disable all nightly tests
One thing I'm realizing now is that we test a number of nightly features
of Cargo/rustc, but if they change in rustc then because
rust-lang/rust's CI run's Cargo's tests it could prevent those changes
from landing! The purpose of running Cargo's tests in CI in
rust-lang/rust is to ensure that Cargo generally works, but there's no
need to test the nightly features as that's Cargo's job.
As a result this adds an environment variable that will be set from
rust-lang/rust's CI which will disable these tests.
One thing I'm realizing now is that we test a number of nightly features
of Cargo/rustc, but if they change in rustc then because
rust-lang/rust's CI run's Cargo's tests it could prevent those changes
from landing! The purpose of running Cargo's tests in CI in
rust-lang/rust is to ensure that Cargo generally works, but there's no
need to test the nightly features as that's Cargo's job.
As a result this adds an environment variable that will be set from
rust-lang/rust's CI which will disable these tests.
Update mdbook to 0.3.
This updates to mdbook 0.3 which uses relative links, which are much better
(the pages mostly work when viewing on GitHub for example).
Remove unused feature filter.
NOTE: Do not merge this lightly. This upended my understanding of how the resolver handles features, and I'm still not sure about it.
Remove an unused check that an optional dependency is activated.
This was originally added 4 years ago in #1812, during a time when this code iterated over the actual dependencies from `Package.dependencies()`. In #5415 this was refactored so that it gets the `deps` list directly from the Resolver, which AFAIK has already filtered out the features. IIUC, this filtering is done [here](705009eb38/src/cargo/core/resolver/dep_cache.rs (L270-L272)).
Also ignore remap-path-prefix in metadata for `cargo rustc`.
Also ignore `--remap-path-prefix` in `cargo rustc`. Who knew that `BuildContext` had 3 sets of arguments?
Closes#7133
Fix some formatting for some strings.
Some of these strings were formatted in a strange way by rustfmt.
Also fixed some strings missing trailing backslashes. Specifically, the "path override for crate" string, and the strings in `http_auth_offered`.
Handle activation conflicts for `[patch]` sources
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Closes#7117
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Closes#7117
