test: add support for features in the sat resolver
### What does this PR try to resolve?
This PR implements the first step of https://github.com/rust-lang/cargo/pull/11938#issuecomment-1868426431.
### How should we test and review this PR?
The first commit does some refactorings, and the second commit updates the SAT resolver.
List of boolean variables in the SAT resolver:
* One variable representing the activation of each registry package.
* One variable representing the activation of each feature of a given registry package.
* In the `sat_resolve()` method, we create an additional representing the activation of the root package.
List of clauses in the SAT resolver:
* If a package feature is activated, then the package should be activated.
* No two packages with the same links set.
* No two semver compatible versions of the same package.
* For each package:
- For each feature:
- If the package feature is activated and it depends of another feature of the same package, then it is also activated.
- If the package feature is activated and it depends of a dependency, then at least one of the compatible dependency package should be activated.
- If the package feature is activated and it depends of a feature of a dependency, then the feature of a compatible dependency package should be activated only if the compatible dependency package is activated. If this is not a weak dependency feature, then at least one of the compatible dependency package should be activated.
- For each dependency, if the package is activated and if the dependency is non-optional or has been activated, then at least one of the compatible dependency package and its required features should be activated.
* The root package has the same dependency clauses but has no features.
List of assumptions in the SAT resolver:
* The root package is activated.
* Old root packages from previous calls to `sat_resolve()` are deactivated. This is necessary since the proptest call `sat_resolve()` several times with a different root package using the same SAT resolver, and clauses relative to the root package are not removable.
feat: lockfile path implies --locked on cargo install
Follow-up of https://github.com/rust-lang/cargo/issues/14421
Resolving one of the items
> cargo install should make --lockfile-path imply --locked
Simply mirrored behavior as if `--locked` was provided (on creating the workspace)
feat(toml): Add `autolib`
### What does this PR try to resolve?
PR #5335 added `autobins`, etc for #5330. Nowhere in there is
discussion of `autolib`.
Cargo script disables support for additional build-targets by disabling
discovery.
Except we don't have a way to disable discovery of `autolib`, leading to #14476.
By adding `autolib`, we can continue in that direction.
This also allows us to bypass inferring of libs on published packages,
like all other build-targets which were handled in #13849.
Fixes#14476
### How should we test and review this PR?
### Additional information
As this seems fairly low controversy, this insta-stabilizes the field.
In prior versions of Cargo, users will get an "unused manifest key"
warning.
For packages where this is set by `cargo publish`, the warning will be suppressed and things will work as normal.
For `cargo vendor`, the same except there will be some churn in the
vendored source as this field will now be set.
For local development, it should be rare to set `autolib` so the lack of
error by discovering a file when this is set shouldn't be a problem.
fix: correct error count for `cargo check --message-format json`
Hi! This is my first time contributing to Cargo. If there is anything that I need to do, please let me know!
(I'm not sure whether the commit message is aligned with the Cargo's convention. If it doesn't, I'm willing to modify it!)
This PR resolves the issue with incorrect error count and ensures warnings are correctly displayed when using `cargo check --message-format json`.
Fixes#14472
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
this relaxes the assertion around that by globbing everything.
feat(timings): support dark color scheme in HTML output
### What does this PR try to resolve?
Use CSS variables to control colors in different modes
Fixes#14586
### How should we test and review this PR?
Switch to dark mode to preview cargo-timing.html file
### Additional information
I am not an expert in CSS. The color table is generated by gpt. Maybe there are other better color schemes.
<img width="1671" alt="Snipaste_2024-09-24_19-36-14" src="https://github.com/user-attachments/assets/5a4556f6-8c5b-4c81-af1d-9d2cdb304201">
<img width="1644" alt="Snipaste_2024-09-24_19-36-50" src="https://github.com/user-attachments/assets/0ae0457c-8fcc-463a-bbb9-ec9e549021b6">
feat: add CARGO_MANIFEST_PATH env variable
Adds `CARGO_MANIFEST_PATH` variable as part of https://github.com/rust-lang/cargo/issues/12207
Context: `CARGO_MANIFEST_DIR` is not very useful, because there is no `Cargo.toml` file when running a cargo script. In cases when multiple scripts are stored in the same folder, we can't tell which script exactly is being run using `CARGO_MANIFEST_DIR`
fix(config): Don't double-warn about `$CARGO_HOME/config`
### What does this PR try to resolve?
The core requirements for this bug are
- You have a `$CARGO_HOME/.config`
- Your project is inside of `$HOME`
We have a check to make sure we don't double-walk `$CARGO/config` but
that check is *after* we warn about there being no `.toml` extension.
To fix this, we just need to move that check outside of the file lookup.
This required changing the `seen` check from checking whether walked the
config file to checking if we've walked the config dir. As we only have
one file per directory, this should work.
Fixes#14560
### How should we test and review this PR?
test commit added the test, fix commit fixed the issue.
### Additional information
The core requirements for this bug are
- You have a `$CARGO_HOME/.config`
- Your project is inside of `$HOME`
We have a check to make sure we don't double-walk `$CARGO/config` but
that check is *after* we warn about there being no `.toml` extension.
To fix this, we just need to move that check outside of the file lookup.
This required changing the `seen` check from checking whether walked the
config file to checking if we've walked the config dir. As we only have
one file per directory, this should work.
fix(cargo-rustc): give trailing flags higher precedence on nightly
### What does this PR try to resolve?
Previously `cargo rustc -- <flags>` got a lower precedence than
some of the flags set by cargo internal.
This is a bit unintuitive as Cargo generally treats user-provided
CLI flags with the highest priority.
This commit changes `cargo rustc -- <flags>` to a higher precedence:
higher than most of flags set by Cargo, and only lower than
`build.rustflags` family.
### How should we test and review this PR?
Unsure if this affects people's workflow, so this behavior is only
enabled on nightly for collectin feedback. A environment variable
`__CARGO_RUSTC_ORIG_ARGS_PRIO=1` is provided for users to opt-out.
If everything goes well, the nightly gate will be removed after a
few of releases.
### Additional information
See discussion on https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rustflags.20precendence.20of.20.60cargo.20rustc.60Fixes#14346
Previously `cargo rustc -- <flags>` got a lower precedence than
some of the flags set by cargo internal.
This is a bit unintuitive as Cargo generally treats user-provided
CLI flags with the highest priority.
This commit changes `cargo rustc -- <flags>` to a higher precedence:
higher than most of flags set by Cargo, and only lower than
`build.rustflags` family.
Unsure if this affects people's workflow, so this behavior is only
enabled on nightly for collectin feedback. A environment variable
`__CARGO_RUSTC_ORIG_ARGS_PRIO=1` is provided for users to opt-out.
If everything goes well, the nightly gate will be removed after a
few of releases.
See discussion on https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rustflags.20precendence.20of.20.60cargo.20rustc.60
feat: make lockfile v4 the default
### What does this PR try to resolve?
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g., `cargo metatada`, status messages,
`SourceID` will display in the v4 URL encoded format.
This shouldn't affect the majority of Rust users,
as `SourceId` representation should be opaque to them,
unless comparing `SourceId` across different version of toolchains.
### How should we test and review this PR?
Some of those tests don't really need to be `version = 4`.
They were updated for consistency.
### Additional information
This was discussed in Cargo meeting on 2024-09-24.
perf: Improve quality of completion performance traces
### What does this PR try to resolve?
- `CompleteEnv::complete` calls `std::process::exit`, causing the traces not to be flushed
- Its hard to see where overhead is coming from for completions without tracing it
This was inspired by #14552
### How should we test and review this PR?
### Additional information
test: Remove completion tests
The tests are intended to spot check that shell completions are registered correctly. That is a low change, low risk area. For shell integration, we're relying on `clap_complete`s tests. For our own candidates, we should test the candidate generation directly, rather than end-to-end.
This reverts parts of commit e7ca9bec80, reversing changes made to bd5f32bb1c.
Fixes#14545
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g., `cargo metatada`, status messages,
`SourceID` will display in the v4 URL encoded format.
This shouldn't affect the majority of Rust users,
as `SourceId` representation should be opaque to them,
unless comparing `SourceId` across different version of toolchains.
feat: Add support for completing `cargo update <TAB>`
### What does this PR try to resolve?
Tracking issue https://github.com/rust-lang/cargo/issues/14520
Add custom completer for `cargo update <TAB>`
PR #5335 added `autobins`, etc for #5330. Nowhere in there is
discussion of `autolib`.
Cargo script disables support for additional build-targets by disabling
discovery.
Except we don't have a way to disable discovery of `autolib`, leading to #14476.
By adding `autolib`, we can continue in that direction.
This also allows us to bypass inferring of libs on published packages,
like all other build-targets which were handled in #13849.
As this seems fairly low controversy, this insta-stabilizes the field.
In prior versions of Cargo, users will get an "unused manifest key"
warning.
For packags where this is set by `cargo publish`, the warning will be suppressed and things will work as normal.
For `cargo vendor`, the same except there will be some churn in the
vendored source as this field will now be set.
For local development, it should be rare to set `autolib` so the lack of
error by discovering a file when this is set shouldn't be a problem.
Fixes#14476
The tests are intended to spot check that shell completions are
registered correctly. That is a low change, low risk area. For shell
integration, we're relying on `clap_complete`s tests.
For our own candidates, we should test the candidate generation
directly, rather than end-to-end.
This reverts parts of commit e7ca9bec80, reversing
changes made to bd5f32bb1c.
Fixes#14545
test: Migrate remaining with_stdout/with_stderr calls
### What does this PR try to resolve?
This is part of #14039 and is another step towards us not needing our own redaction logic.
Along the way, I switched us to using `expect` to make it easier to tell when `allow(deprecated)` should be removed.
### How should we test and review this PR?
### Additional information
fix(resolve): Improve multi-MSRV workspaces
### What does this PR try to resolve?
We do this by resolving for a package version that is compatible
with the most number of MSRVs within a workspace.
If a version requirement is just right, every package will get the
highest MSRV-compatible dependency.
If its too high, packages will get MSRV-incompatible dependency
versions.
This will happen regardless of what we do due to the nature of
`"fallback"`.
If its too low, packages with higher MSRVs will get older-than-necessary
dependency versions.
This is similar to the "some with and without MSRV" workspaces.
When locking dependencies, we do report to users when newer MSRV/SemVer
compatible dependencies are available to help guide them to upgrading if
desired.
Fixes#14414
### How should we test and review this PR?
Is this the right behavior?
- This feature is unstable and letting people try it is one way to determine that
- A concern was raised within the Cargo team about new users with workspace member MSRVs all set to latest having someone ask them to lower an MSRV and them dealing with staler-than-required dependencies
- At this point, there seems to be agreement on #14414 being a problem, the resolver magically fixing this is unlikely to happen for the foreseeable future, and this does fix it with the potential for user confusion. From my understanding of those conversations, they are mostly in the area of UX, like with #14543. Rather than blocking on that discussion, this moves forward with the implementation.
### Additional information
