Fix .gitignore of Cargo.lock in a subdirectory.
The code for checking if `Cargo.lock` is ignored was erroneously assuming it was at the root of the git repo. This would cause a problem if `Cargo.lock` is in `.gitignore` in a subdirectory.
Fixes issue noted in https://github.com/rust-lang/cargo/issues/7705#issuecomment-572027382
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
Credentials are always loaded, even if these are not used. If
access to confidential files such as credentials is not given,
`cargo build` fails despite not using credentials.
Fixes#7624.
Fix CARGO_TARGET_triple_LINKER environment variable.
#7649 caused an unfortunate regression where the `CARGO_TARGET_triple_LINKER` environment variable stopped working. I did not realize `serde(flatten)` caused serde to switch to `deserialize_map` which does not support environment variables.
The solution here is to essentially revert back to how the `[target]` table used to be loaded by loading each key individually.
This also removes the `ar` field which is not used by `rustc`.
Remove metadata dep_kinds duplicates.
In `cargo metadata`, an entry could appear multiple times in the `dep_kinds` array if it is used by multiple workspace members with different features activated. This fixes it by de-duplicating the entries.
This is kinda related to `cargo metadata` not handling workspaces and features very well. But workspaces and features are a bit awkward overall.
Fixes#7752
Check for a source defined multiple times.
There is a bug where if a source is defined in multiple `[source]` tables, it causes a key collision in `SourceConfigMap::id2name`. This can result in random behavior depending on which key is inserted first.
I decided to just make it an error. I can't think of a way to make it work since the `replace-with` chain walking depends on unique sourceid->name mappings. If anyone has ideas how to support it, I can try, but I don't immediately see how.
Closes#7692
Fix config env vars that are prefix of another with underscore.
This fixes the CARGO_BUILD_TARGET_DIR and CARGO_PROFILE_DEV_DEBUG_ASSERTIONS environment variables. Hopefully the big comment explains everything, but to review:
`deserialize_option` does not know the type of the value it is about to deserialize. The type could be a struct, in which case it needs to check if `CARGO_FOO_BAR_*` environment variables are set. However, when deserializing something like `build.target`, this prefix check will incorrectly match `CARGO_BUILD_TARGET_DIR` which happens to be a prefix of `CARGO_BUILD_TARGET_*`. It attempts to call `visit_some` which fails if `CARGO_BUILD_TARGET` is not set.
The solution here is to detect scenarios where one field is a prefix of another, and skip the environment prefix check (by setting `Deserializer::env_prefix_ok` appropriately). This means we cannot have `Option<SomeStruct>` be a prefix of another field with an underscore. I think that's fine, and we should try to probably avoid these kinds a prefixes anyways.
Closes#7253.
vendor: support alt registries
Adds support for alt registries to `cargo vendor`. It mostly worked before, but panicked when trying to display the `.cargo/config` instructions.
This isn't entirely elegant, as the source replacement looks like this:
```toml
[source.crates-io]
replace-with = "vendored-sources"
[source."file:///Users/eric/Proj/rust/cargo/target/cit/t0/alternative-registry"]
registry = "file:///Users/eric/Proj/rust/cargo/target/cit/t0/alternative-registry"
replace-with = "vendored-sources"
[source."file:///Users/eric/Proj/rust/cargo/target/cit/t0/gitdep"]
git = "file:///Users/eric/Proj/rust/cargo/target/cit/t0/gitdep"
branch = "master"
replace-with = "vendored-sources"
[source.vendored-sources]
directory = "vendor"
```
The duplication of the URLs is a little unfortunate. It could use the name of the registry, but that is not readily available and is tricky to obtain. I feel like that is a challenge for another day.
Closes#7674.
Add proc_macro to the extern prelude.
This makes it so that a proc-macro library can use the `proc_macro` crate without the `extern crate proc_macro;` item on the 2018 edition. This is the Cargo half of https://github.com/rust-lang/rust/pull/64882.
vendor: implement --versioned-dirs
Implement `--explicit-version` from standalone cargo-vendor. This helps with vendoring
performance as it avoids redundantly deleting and re-copying already vendored packages.
For example, re-vendoring cargo's dependencies it makes a big difference in wallclock
time. For initial vendoring it makes no difference, but re-vendoring (ie, when most or all dependencies haven't changed) without explicit versions is actually slightly slower
(5.8s -> 6s), but with explicit versions it goes from 5.8s -> 1.6s.
Timings:
Without explicit versions, initial vendor
real 0m5.810s
user 0m0.924s
sys 0m2.491s
Re-vendor:
real 0m6.083s
user 0m0.937s
sys 0m2.654s
With explicit versions, initial vendor:
real 0m5.810s
user 0m0.937s
sys 0m2.461s
Re-vendor:
real 0m1.567s
user 0m0.578s
sys 0m0.967s
Its interesting to look at the syscall summary:
Without explicit versions:
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
25.17 1.104699 18 59432 1065 openat
19.86 0.871574 21 41156 13825 unlink
13.64 0.598739 2 210510 lstat
9.02 0.395948 29 13208 copy_file_range
8.00 0.351242 11 30245 read
6.36 0.279005 3 72487 4476 statx
5.35 0.235027 6 37219 write
4.02 0.176267 3 58368 close
```
with explicit versions:
```
29.38 0.419068 15 27798 13825 unlink
25.52 0.364021 1 209586 lstat
20.67 0.294788 16 17967 1032 openat
10.42 0.148586 4 35646 write
3.53 0.050350 3 13825 chmod
3.14 0.044786 2 16701 1622 statx
2.19 0.031171 1 16936 close
1.86 0.026538 24 1078 rmdir
```
Specifically, there are a lot fewer opens, copy_file_ranges, and unlinks.
Add and move tests for jobs of `cargo build`
A test when argument is negative is added. In addition, `default_cargo_config_jobs` and `good_cargo_config_jobs` is moved from `testsuite/bad_config.rs` to `testsuite/build.rs` because these tests are not for `bad config`.
include dotfiles in packages
This PR solves #7183
It changes the behavior of `cargo package` to also include dotfiles by default.
It should be discussed if this is intended or if the implementation should be changed to only include dotfiles which are specified in the `include` section.
From the [existing comment](40885dfab4/src/cargo/sources/path.rs (L358)) it is a little bit unclear to me, but I supposed it was intended only to exclude directories starting with a dot?
A test when argument is negative is added. In addition,
`default_cargo_config_jobs` and `good_cargo_config_jobs` is moved from
`testsuite/bad_config.rs` to `testsuite/build.rs` because these tests
are not for `bad config`.
Implement --explicit-version from standalone cargo-vendor. This helps with
vendoring performance as it avoids redundantly deleting and re-copying
already vendored packages.
For example, when re-vendoring cargo's dependencies it makes a big
improvement on wallclock time. For initial vendoring it makes no
difference, but re-vendoring (ie, when most or all dependencies haven't
changed) without explicit versions is actually slightly slower (5.8s ->
6s), but with explicit versions it goes from 5.8s -> 1.6s.
Timings:
Without explicit versions, initial vendor
real 0m5.810s
user 0m0.924s
sys 0m2.491s
Re-vendor:
real 0m6.083s
user 0m0.937s
sys 0m2.654s
With explicit versions, initial vendor:
real 0m5.810s
user 0m0.937s
sys 0m2.461s
Re-vendor:
real 0m1.567s
user 0m0.578s
sys 0m0.967s
The summaries of syscalls executed shows why:
Revendoring without explicit versions:
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
25.17 1.104699 18 59432 1065 openat
19.86 0.871574 21 41156 13825 unlink
13.64 0.598739 2 210510 lstat
9.02 0.395948 29 13208 copy_file_range
8.00 0.351242 11 30245 read
6.36 0.279005 3 72487 4476 statx
5.35 0.235027 6 37219 write
4.02 0.176267 3 58368 close
```
with explicit versions:
```
29.38 0.419068 15 27798 13825 unlink
25.52 0.364021 1 209586 lstat
20.67 0.294788 16 17967 1032 openat
10.42 0.148586 4 35646 write
3.53 0.050350 3 13825 chmod
3.14 0.044786 2 16701 1622 statx
2.19 0.031171 1 16936 close
1.86 0.026538 24 1078 rmdir
```
Specifically, there are a lot fewer opens, copy_file_ranges, and unlinks.
Remove --offline empty index error.
This reverts the error added in #6871 which attempts to provide a "nicer" error message if `--offline` is used with an empty index. I was concerned about false positives, and sure enough someone found one. If all deps are patched, it is OK for the index to be empty, because the resolver will just use the patched entries.
I considered trying to move the error to another location, but I think it would require significant changes to the registry API (which is already hard to follow). I figure the "not found" error message is good enough with the "don't use --offline" hint.
Closes#7582
cargo currently generates a .gitignore file that ignores .rs.bk files,
historically because rustfmt would sometimes generate such files.
However, rustfmt and cargo fmt don't generate backup files by default
(only when requested), and even when requested, they generate .bk files,
not .rs.bk files (as of rustfmt commit
fad903fd14ad0df045dc574cac0717312860c380 in 2017). And nobody seems to
have noticed or complained since then, likely because rustfmt doesn't
generate backup files by default.
rustfmt also plans to deprecate the --backup option entirely, in rustfmt
2.0, and instead always rely on version control to track changes.
In addition, these types of ignores, just like ignores of editor backup
files, don't belong in .gitignore; they belong in people's personal
ignore files, such as ~/.config/git/ignore. See
https://julien.danjou.info/properly-managing-your-gitignore/ for further
explanation of that.
Given all three of those factors, drop the code to add **/*.rs.bk to
.gitignore, and update tests accordingly.
Stabilize profile-overrides.
This stabilizes the profile-overrides feature. This was proposed in [RFC 2282](https://github.com/rust-lang/rfcs/pull/2282) and implemented in #5384. Tracking issue is https://github.com/rust-lang/rust/issues/48683.
This is intended to land in 1.41 which will reach the stable channel on Jan 30th.
This includes a new documentation chapter on profiles. See the ["Overrides" section](9c993a92ce/src/doc/src/reference/profiles.md (overrides)) in `profiles.md` file for details on what is being stabilized.
Note: The `config-profile` and `named-profiles` features are still unstable.
Closes#6214
**Concerns**
- There is some risk that `build-override` may be confusing with the [proposed future dedicated `build` profile](https://github.com/rust-lang/cargo/pull/6577). There is some more discussion about the differences at https://github.com/rust-lang/rust/issues/48683#issuecomment-445571286. I don't expect it to be a significant drawback. If we proceed later with a dedicated `build` profile, I think we can handle explaining the differences in the documentation. (The linked PR is designed to work with profile-overrides.)
- I don't anticipate any unexpected interactions with `config-profiles` or `named-profiles`.
- Some of the syntax like `"*"` or `build-override` may not be immediately obvious what it means without reading the documentation. Nobody suggested any alternatives, though.
- Configuring overrides for multiple packages is currently a pain, as you have to repeat the settings separately for each package. I propose that we can extend the syntax in the future to allow a comma-separated list of package names to alleviate this concern if it is deemed worthwhile.
- The user may not know which packages to override, particularly for some dependencies that are split across multiple crates. I think, since this is an advanced feature, the user will likely be comfortable with using things like `cargo tree` to understand what needs to be overridden. There is [some discussion](https://github.com/rust-lang/rust/issues/48683#issuecomment-473356415) in the tracking issue about automatically including a package's dependencies, but this is somewhat complex.
- There is some possibly confusing interaction with the test/bench profile. Because dependencies are always built with the dev/release profiles, overridding test/bench usually does not have an effect (unless specifying a workspace member that is being tested/benched). Overriding test/bench was previously prohibited, but was relaxed when named profiles were added.
- We may want to allow overriding the `panic`, `lto`, and `rpath` settings in the future. I can imagine a case where someone has a large workspace, and wants to override those settings for just one package in the workspace. They are currently not allowed because it doesn't make sense to change those settings for rlibs, and `panic` usually needs to be in sync for the whole profile.
- There are some strange interactions with `dylib` crates detailed in https://github.com/rust-lang/rust/issues/64319. A fix was attempted, but later reverted. Since `dylib` crates are rare (this mostly applied to `libstd`), and a workaround was implemented for `build-std` (it no longer builds a dylib), I'm not too worried about this.
- The interaction with `share-generics` can be quite confusing (see https://github.com/rust-lang/rust/issues/63484). I added a section in the docs that tries to address this concern. It's also possible future versions of `rustc` may handle this better.
- The new documentation duplicates some of the information in the rustc book. I think it's fine, as there are subtle differences, and it avoids needing to flip back and forth between the two books to learn what the settings do.
Minor testsuite organization.
I sometimes get a little lost when looking for the right module for tests. This adds a brief comment to each one explaining what it is. This also includes a few renamed modules, and a few tests have been placed in a location that makes a little more sense to me. There shouldn't be any functional changes here.
- Move `build_lib` into `build`. It seemed a little strange to have these tests floating in a separate file.
- Rename `build_auth` to `git_auth`.
- Rename `small_fd_limits` to `git_gc`.
- Rename `resolve` to `minimal_versions`.
- Rename `overrides` to `replace`.
- Pull out `paths` overrides tests into a separate file.
Add value OUT_DIR to build-script-executed JSON message
The target audience here is IDE authors, who can use this feature to
better support crates which generate code to OUT_DIR
Document private items for binary crates by default
I suggested this change in default behavior [a long time ago](https://github.com/rust-lang/cargo/issues/1520#issuecomment-135215284) and [a year ago again](https://github.com/rust-lang/cargo/issues/1520#issuecomment-420616261). Both time, everyone seemed to agree that this is a good idea, so I thought I could just implement it.
This PR already changed the default behavior, but there are a few things we should talk about/I should do before merging:
- [x] ~~Do we *really* want this changed default behavior? If not, *why* not?~~ -> [yip](https://github.com/rust-lang/cargo/pull/7593#issuecomment-556482199)
- [x] Is changing this default behavior OK regarding backwards compatibility? -> [apparently](https://github.com/rust-lang/cargo/pull/7593#issuecomment-556482199)
- [x] ~~We should also probably add a `--document-only-public-items` flag or something like that if we change the default behavior. Otherwise users have no way to not document private items for binary crates. Right?~~ -> [We can do it later](https://github.com/rust-lang/cargo/pull/7593#issuecomment-557152039)
- [x] I should probably add some tests for this new behavior -> I did
- [ ] I don't like that I added `rustdoc_document_private_items` to `CompileOptions`, but this was the sanest way I could think of without rewriting a whole lot. Is this OK or how else would one do it? The flag would belong to `DocOptions`. But `compile` does not have access to that. Any ideas? Btw: If we also add `--document-only-private-items`, I would change the type from `bool` to `Option<bool>`.
Stabilize install-upgrade.
Tracking issue: #6797
This stabilizes the install-upgrade feature, which causes `cargo install` to reinstall a package if it appears to be out of date, or exit cleanly if it is up-to-date.
There are no changes from `-Zinstall-upgrade`. See [the old unstable docs](6a7f505a18/src/doc/src/reference/unstable.md (install-upgrade)) for a refresher on the details of what it does.
This also stabilizes the following changes:
- `--version` no longer allows an implicit version requirement like `1.2`. It must be either contain all 3 components (like `1.2.3`) or use a requirement operator (like `^1.2`). This has been a warning for a very long time, and is now changed to a hard error.
- Added `--no-track` to disable install tracking.
**Motivation**
I just personally prefer this behavior, and it has been requested a few times in the past. I've been using it locally, and haven't run into any issues. If this goes into 1.41, then it will release on Jan 30, about 10 months since it was added in #6798.
**Concerns**
Regarding some of the concerns I had:
- Is it tracking the correct set of information?
I'm satisfied with the current set. It also tracks, but does not use, the version of rustc and the version specified in the `--version` flag, in case we ever want to use that in the future. It is also designed to be backwards and forwards compatible, so more information can be added in the future. I think the current set strikes a good balance of tracking the really important things, without causing unnecessary rebuilds.
- Method to upgrade all outdated packages?
This can always be added as a new flag or command in the future, and shouldn't block stabilization.
- Should `--no-track` be kept? Does it work correctly?
I kept it. It's not too hard to support, and nobody said anything (other than maybe using a less confusing name).
- Should this be the default? Should there be a way to use the old behavior?
I like it as the default, and don't see a real need for the old behavior. I think we could always bring back the old behavior with a flag in the future, but I would like to avoid it for simplicity. There is also the workaround of `which foo || cargo install foo`.
Closes#6797.
Closes#6727.
Closes#6485.
Closes#2082.
Turn the new lock file format on by default
This commit enables the support added in #7070 by default. This means
that gradually over time all `Cargo.lock` files will be migrated to the
new format. Cargo shipped with Rust 1.38.0 supports this new lock file
format, so any project using Rust 1.38.0 or above will converge quickly
onto the new lock file format and continue working.
The main benefit of the new format is to be more friendly to git merge
conflicts. Information is deduplicated throughout the lock file to avoid
verbose `depedencies` lists and the `checksum` data is all listed inline
with `[[package]]`. This has been deployed with rust-lang/rust for some
time now and it subjectively at least seems to have greatly reduced the
amount of bouncing that happens for touching `Cargo.lock`.
Fix all Clippy suggestions (but not add it to CI 🙃)
This PR adds a `clippy` job to the Azure Pipelines CI.
In addition to adding the job, I made sure to fix all the lints in all the packages.
I'm new to Rust, so please check my code modifications extra carefully 😂
Add kind/platform info to `cargo metadata`
This adds an array `"dep_kinds"` to the resolve nodes of the `cargo metadata` output. It looks something like this:
```javascript
"resolve": {
"nodes": [
"id": "cargo 0.39.0 (path+file:///Users/eric/Proj/rust/cargo2)",
"deps": [
{
"name": "bufstream",
"pkg": "bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
"dep_kinds": [
{
"kind": "dev",
"target": null
}
]
},
{
"name": "winapi",
"pkg": "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
"dep_kinds": [
{
"kind": null,
"target": "cfg(windows)"
}
]
}
]
]
}
```
This allows one to filter the graph based on the dependency kind and platform.
I'm not completely confident that this is the right course, but I can't think of a better design. In particular, it seems a little strange to include all platforms, but features get filtered. This is probably not a problem in practice (one can use `--all-features` to ensure all features are shown for the top-level packages). Filtering out based on platform is very difficult, because you cannot determine from the resolve alone which nodes will be host vs target. That requires the entire Unit graph. We may expose the Unit graph in the future, but this seems like a useful and simple step.
This is a draft because I wanted to discuss this before moving forward. I'd like to add some more tests.
cc #4632. This doesn't filter based on target, but does expose the target names. As mentioned above, I don't think filtering is possible.
cc #5583. This adds more information.
Closes#3984.
Closes#4631 (I think).
cc @sfackler who filed some of these issues.
This commit adds support to Cargo and refactors the lockfile versioning
slightly. The goal here is that Cargo continually has two thresholds of
lockfile formats to create:
* One is used for new lock files at all times
* The other is used to update old lock files
The logic for these two thresholds is appropriately updated throughout
Cargo, and then this commit also preserves the previous update where new
lock files will get the new format, but old lockfiles will continue to
retain the old format by default.
This commit enables the support added in #7070 by default. This means
that gradually over time all `Cargo.lock` files will be migrated to the
new format. Cargo shipped with Rust 1.38.0 supports this new lock file
format, so any project using Rust 1.38.0 or above will converge quickly
onto the new lock file format and continue working.
The main benefit of the new format is to be more friendly to git merge
conflicts. Information is deduplicated throughout the lock file to avoid
verbose `depedencies` lists and the `checksum` data is all listed inline
with `[[package]]`. This has been deployed with rust-lang/rust for some
time now and it subjectively at least seems to have greatly reduced the
amount of bouncing that happens for touching `Cargo.lock`.
Only include "already existing ..." comment in gitignore on conflict
I found the comment a bit confusing when I've used `cargo init` when I haven't had any conflicts. I thought it was meaning that my existing entries would be all commented out so I thought there was a bug of some kind.
This PR changes the comment to only be included when there are conflicting entries in the existing file.
Fix profile override warning in a workspace.
Profile overrides would erroneously warn about unused packages in a workspace if the package was not being built. The fix here is to retain the `Resolve` for the entire workspace, and use that to determine the valid set of packages.
I think it would be good for a long-term goal to get rid of the second ("targeted") resolve. I'm still contemplating how a separate features resolver could achieve that, but it seems feasible long-term.
Closes#7378
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag
to the compiler itself will activate a mode in the `test` crate which
enables running tests even if they're compiled with `panic=abort`. It
effectively runs a test-per-process.
This commit brings the same support to Cargo, adding a `-Z
panic-abort-tests` flag to Cargo which allows building tests in
`panic=abort` mode. While I wanted to be sure to add support for this in
Cargo before we stabilize the flag in `rustc`, I don't actually know how
we're going to stabilize this here. Today Cargo will automatically
switch test targets to `panic=unwind`, and so if we actually were to
stabilize this flag then this configuration would break:
[profile.dev]
panic = 'abort'
In that case tests would be compiled with `panic=unwind` (due to how
profiles work today) which would clash with crates also being compiled
with `panic=abort`. I'm hopeful though that we can perhaps either figure
out a solution for this and maybe even integrate it with the ongoing
profiles work.
rustfmt for nightly changes.
Something in the latest nightly versions of rustfmt has slightly changed the logic here. Fortunately stable ignores the new formatting, and it looks better to me anyways. I tend to always use nightly, so this helps me with a slight annoyance where this line keeps getting changed.
Reject feature flags in a virtual workspace.
This generates an error if feature flags are used in the root of a virtual workspace. Previously these flags were completely ignored. In the interest of avoiding confusion, I think it would be good to be explicit that these don't currently work. This could alternatively be a warning, but I think it is better to reject it outright.
cc #4753, #3620, #5015, #6195, etc.
Allow publishing with dev-dependencies without a version.
This change allows dev-dependencies without a `version` key to be published. If a dev-dependency is missing the `version`, it will be stripped from the packaged manifest.
Stabilize cache-messages
This stabilizes the -Zcache-messages feature, making it always enabled.
## What is stabilized?
This feature is intended to redisplay previous warnings on a "fresh" build instead of displaying no output.
Users have occasionally indicated frustration when they know there are warnings, but no output is displayed when the build is fresh. This also improves the interaction between `cargo check` and `cargo clippy-preview`. This also simplifies the code, and opens more possibilities for `rustc` to send side-channel messages to Cargo.
Cargo will now use JSON output from `rustc` and `rustdoc` 100% of the time (`rustdoc --test` does not use JSON). Previously Cargo would only use JSON for pipelined crates.
Cargo will save the JSON output into a file named `output` in the `.fingerprint` directory. This file is only created when the compiler outputs a diagnostic message.
If a crate is being recompiled, and Cargo considers it to be "fresh", it will replay the output file to the console.
## Notable changes in this PR
- Fixed a bug where replays were erroneously including pipeline rmeta artifact json messages.
- clippy-preview is now included in the metadata hash, to force its artifacts to be separate from `cargo check`.
- clippy-preview is no longer force-enabled, under the assumption that caching and fingerprinting is accurate, and the cached messages will be replayed.
- clippy-preview's arguments are included in the fingerprint now that it is not force-enabled.
- Rustdoc colors and short messages were fixed when pipelining was stabilized, so updated tests.
Closes#6986Closes#6848Closes#6664Closes#2458
## Concerns
The only notable issue with this is that switching between short and long human messages only replays the format from the first invocation. That is, if you do `cargo build` and it generates warnings, then running again with `--message-format=short` will still show the full length human messages. I'm personally fine with that behavior, even though it is not ideal. I think this feature overall improves the situation (where before *no* output was displayed). Being able to re-render between short/long is a very difficult problem, and unlikely to be fixable in the foreseeable future.
There was some concern expressed about being able to disable this. I think that would only be necessary if a severe bug is discovered. I do not feel that this change is risky enough to warrant a configurable option. If it does cause a problem, it can be quickly reverted with a one-line change to set `OutputOptions::cache_cell` to `None`. Since pipelining has been using JSON output for a while now without complaints, I feel pretty confident in it.
Migrate towards exclusively using serde for `Config`
This series of commits was spawned off a thought I had while reading https://github.com/rust-lang/cargo/issues/7253#issuecomment-535656059, although it ended up not really touching on that at all. I was a little unsettled about how unstructured the config accesses are throughout Cargo and we had sort of two systems (one serde which is nice, one which is more manual) for reading config values.
This PR converts everything to run through serde for deserializing values, except for `get_list` which is funky. There's only one usage of that with the `paths` key though and we can probably fix this soon-ish.
In any case, the highlights of this PR are:
* This PR is surprisingly large. I did a lot of movement in `config.rs` to try to make the file smaller and more understandable.
* The `Value` type which retains information about where it was deserialized from is very special, and has special treatment with serde's data model. That's what allows us to use that and serde at the same time.
* The `ConfigRelativePath` and `ConfigKey` structures have been revamped internally, but morally serve the same purposes as before.
* Cargo now has structured `struct` access for a bunch of its configuration (`net`, `http`, `build`, etc). I would ideally like to move toward a world where this is the *only* way to read configuration, or at least everything conventionally runs through those paths.
* Functionally, this PR should have no difference other than tweaks to error messages here and there, and perhaps more strict validation on commands where we validate more configuration on each run than we previously did.
* This isn't a 100% transition for Cargo yet, but I figured it would be a good idea to post this and get some feedback first.
* In the long run I want to remove `get_env`, `get_cv`, and `get_*_priv` from `Config` as internal details. I'd like to move this all to `de.rs` and have it walk down the tree of configuration as we deserialize a value. For now though these all remain in place and that refactoring is left to a future PR.
Rewrite helpers like `get_bool` to use `get::<Option<Value<bool>>>`
instead of duplicating the logic that's already with the typed access of
configuration. This is more along the effort to centralize all
deserialization of configuration into typed values instead of using
ad-hoc accessors in a number of locations.
Also make it a little less allocation-heavy by tweaking the API to
encourage incremental building of the key and incremental destruction as
we walk throughout the configuration tree.
First reported in rust-lang/rust#65014 it looks like our error message
on cyclic dependencies may be confusing at times. It looks like this is
an issue because there are multiple paths through a graph for a
dependency, so using the generic `path_to_top` function isn't producing
the most useful path for this purpose.
We're already walking the graph though, so this commit adds an extra
parameter which collects the list of packages we've visited so far to
produce a hopefully always-accurate error message showing the chain of
dependencies end-to-end for what depends on what.
Go back to not hashing `RUSTFLAGS` in `-Cmetadata`
This is a moral revert of #6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.
Closes#7416
The effects over the profile used by targets are made conditional
in this commit, using the old scheme if the `named-profiles` feature
is disabled. This also affects the `profile_targets` tests, which
now have two modes - stable, and nightly with the feature enabled.
Bug7346/transitive patches
Fixes#7346.
A cursory comparison between current stable and nightly shows that projects with this topology resolve similarly. If there are other behaviors I should test, I'd be happy to expand that section. This is a pretty focused change, though, so I'm not sure what else there is to break.
Sorry about the delay in putting this PR together. Good news is I know more than I did last week.
Improve test output with `--quiet`
We had a few locations where the shell was written to raw instead of
through the test harness or through other captured mechanisms. This
updates the test suite so testing Cargo with `--quiet` provides a nice
and clean report of tests executed.
We had a few locations where the shell was written to raw instead of
through the test harness or through other captured mechanisms. This
updates the test suite so testing Cargo with `--quiet` provides a nice
and clean report of tests executed.
This is a moral revert of #6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.
Closes#7416
Change build-std to use --sysroot
This transitions build-std to use `--sysroot` instead of `--extern`. This is necessary because existing crates have a certain expectation of how standard library crates are exposed. It was intended that explicit dependencies in `Cargo.toml` would solve this problem, but I didn't really consider this would be a backwards-incompatible change, so using `--sysroot` is probably the best way to go, even though it's not ideal.
Closesrust-lang/wg-cargo-std-aware#31Closesrust-lang/wg-cargo-std-aware#40
* Minimize the sysroot crates in play
* Don't use build scripts to inject args
* Use `RUSTC_WRAPPER` to dynamically switch `--sysroot` depending on
whether we're building sysroot crates or not.
* Minimize dependency graph in sysroot, only have each crate depend on a
dummy crates.io crate for testing and otherwise don't depend on
anything to load the desired sysroot crate directly.
