The `-Znext-lockfile-bump` is added, so we can prepare for all
lockfile format changes and then stabilize then all at once.
`-Znext-lockfile-bump` is not intended for using outside our test
suite and development. Hence it's hidden.
To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
This also exposes the fact that we didn't disable `autobins` like the
documentation says we should.
Background: the hash existed for sharing a target directory. That code isn't
implemented yet and a per-user build cache might remove the need for it,
so let's remove it for now and more carefully weigh adding it back in.
Immediate: This reduces the chance of hitting file length issues on Windows.
Generally: This is a bit hacky and for an official solution, we should
probably try to find a better way. This could become more important as
single-file packages are allowed in workspaces.
Emit error when users try to use a toolchain via the `add` or `install` command
Running `cargo install +nightly` or `cargo add +nightly` does not actually use the nightly toolchain, but the user won't know until the compilation fails. With this PR, an error is emitted if the `install` and `add` command is given a crate name
that starts with a `+` as we assume the user's intention was to use a certain toolchain instead of installing/adding a crate.
Example:
<img width="758" alt="image" src="https://github.com/rust-lang/cargo/assets/45989466/16e59436-32ee-49ee-9933-8b68b176c09d">
Fixes#10362
This commit adds support for passing the keyword "default"
to either the CLI "--jobs" argument on the "[build.jobs]"
section of ".cargo/config".
This is dony by:
1. Changing the "jobs" config type to an enum that holds
a String or an Integer(i.e. i32).
2. Matching the enum & casting it to an integer
Signed-off-by: Charalampos Mitrodimas <charmitro@gmail.com>
It was unnecessary to pass `spilt-debuginfo` if there is no debuginfo.
Tests are touched here only for matching rustflags invocation stderr
in the original test suite.
Previously, `Debuginfo::None` meant "don't pass -C debuginfo" and `Explicit(None)` meant
"-C debuginfo=0", which occasionally led to caching bugs where cargo would sometimes pass
`-C debuginfo=0` and sometimes not. There are no such bugs currently that we know of, but
representing them the same within cargo avoids the possibility of the bug popping up again in the
future.
I tested the `with_stderr_does_not_contain_tests` with this diff to ensure they did not pass:
```diff
diff --git a/src/cargo/core/compiler/mod.rs b/src/cargo/core/compiler/mod.rs
index 55ec17182..c186dd00a 100644
--- a/src/cargo/core/compiler/mod.rs
+++ b/src/cargo/core/compiler/mod.rs
@@ -1073,9 +1073,7 @@ fn build_base_args(
let debuginfo = debuginfo.into_inner();
// Shorten the number of arguments if possible.
- if debuginfo != TomlDebugInfo::None {
cmd.arg("-C").arg(format!("debuginfo={}", debuginfo));
- }
cmd.args(unit.pkg.manifest().lint_rustflags());
if !rustflags.is_empty() {
```
fix(add): Reduce the chance we re-format the user's `[features]` table
### What does this PR try to resolve?
#11743 pointed out that we re-format the users `[features]` table when running `cargo add` which was a bug introduced in #11099.
This reduces the chance people will run into this problem
- Reducing the scope of the `fmt` call
- Preserving formatting in a simple case
Actually removing the `fmt` case can make some common formatting cases more complex to do "right", so I'm punting on that for now.
### How should we test and review this PR?
Look at the individual commits as I show how each change improves the behavior of `cargo add`.
This is a carry-over from cargo-edit where we had to worry about the UX
of all of the behavior while now we are just relying on built-in cargo
behavior and don't need to test it specifically for `cargo add`.
On my machine, this test takes 11s.
refactor(tests): Reduce cargo-add setup load
This just gets rid of irrelevant packages in the registry. Looking into which versions aren't needed would require a deeper pass, so I held off on that for now.
Before, the tests were in the 300-500ms range and now they take 100-300ms.
This did call to my attention that `unrelated` is misspelled as `unrelateed` but holding off on fixing that to reduce conflicts.
Warn when an edition 2021 crate is in a virtual workspace with default resolver
Edition 2021 updates the default resolver to version "2", but developers using virtual workspaces commonly don't get this update because the virtual workspace defaults to version "1". Warn when this situation occurs so those developers can explicitly configure their workspace and will be more likely to know that they will need to update it in the future.
Fixes#10112
This just gets rid of irrelevant packages in the registry. Looking into
which versions aren't needed would require a deeper pass, so I held off
on that for now.
Before, the tests were in the 300-500ms range and now they take
100-300ms.
This did call to my attention that `unrelated` is misspelled as
`unrelateed` but holding off on fixing that to reduce conflicts.
Edition 2021 updates the default resolver to version "2", but developers
using virtual workspaces commonly don't get this update because the
virtual workspace defaults to version "1". Warn when this situation
occurs so those developers can explicitly configure their workspace and
will be more likely to know that they will need to update it in the
future.
refactor(tests): Reduce cargo-remove setup load
This reduces the number of packages published in tests. This is an artifact of when I changed `cargo-edit` from relying on crates.io to test-generated published packages. I took the fastest path to making that conversion and took the shortcut of creating everything for every test. I had assumed the cost was low but `@Muscraft` noticed that this takes up a lot of space which we run out of on CI occasionally and I expect a lot of small files are slowing down windows.
This only updates `cargo-remove`. I'll be doing a follow up for `cargo-add`.
fix(lints): Switch to -Zlints so stable projects can experiment
### What does this PR try to resolve?
In #12115, we explored how we can let stable projects
experiment with `[lints]` to provide feedback. What we settled on is
switching from the `cargo-features` manifest key to the `-Z` flag as
`cargo-features` always requires nightly while `-Z` only requires it
when being passed in. This means a project can have a `[lints]` table
and have CI / contributors run `cargo +nightly check -Zlints` when they
care about warnings.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your PR.
With a smooth review process, a pull request usually gets reviewed quicker.
If you don't know how to write and run your tests, please read the guide:
https://doc.crates.io/contrib/tests
### Additional information
I considered reworking the code to show the user the errors they would encounter once the feature is stable but held off. I wasn't quite sure what language to use and most likely a user would have something doing error reporting, like CI, so it should be fine.
feat: `lints` feature
### What does this PR try to resolve?
Implement rust-lang/rfcs#3389 which shifts a subset of `.cargo/config.toml` functionality to `Cargo.toml` by adding a `[lints]` table.
This **should** cover all of the user-facing aspects of the RFC
- This doesn't reduce what flags we fingerprint
- This will fail if any lint name as `::` in it. What to do in this case was in the RFC discussion but I couldn't find the thread to see what all was involved in that discussion
- This does not fail if a `[lints]` table is present or malformed unless nightly with the `lints` feature enabled
- The idea is this will act like a `[lints]` table is present in an existing version of rust, ignore it
- The intent is to not force an MSRV bump to use it.
- When disabled, it will be a warning
- When disabled, it will be stripped so we don't publish it
Tracking issue for this is #12115.
### How should we test and review this PR?
1. Look at this commit by commit to see it gradually build up
2. Look through the final set of test cases to make sure everything in the RFC is covered
I tried to write this in a way that will make it easy to strip out the special handling of this unstable feature, both in code and commit history
### Additional information
I'd love to bypass the need for `cargo-features = ["lints"]` so users today can test it on their existing projects but hesitated for now. We can re-evaluate that later.
I broke out the `warn_for_feature` as an experiment towards us systemitizing this stabilization approach which we also used with #9732. This works well when we can ignore the new information which isn't too often but sometimes happens.
This does involve a subtle change to `profile.rustflags` precedence but
its nightly and most likely people won't notice it? The benefit is its
in a location more like the rest of the rustflags.
In rust-lang/cargo#12115, we explored how we can let stable projects
experiment with `[lints]` to provide feedback. What we settled on is
switching from the `cargo-features` manifest key to the `-Z` flag as
`cargo-features` always requires nightly while `-Z` only requires it
when being passed in. This means a project can have a `[lints]` table
and have CI / contributors run `cargo +nightly check -Zlints` when they
care about warnings.
