According to [documentation] looks like this value is documented as it
can decrease, so let's handle that without overflowing.
[documentation]: http://man7.org/linux/man-pages/man5/proc.5.html
Load credentials only when needed
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.
This fixes a regression from #7475 where the sysroot_target_libdir leaks into
the host libdir. This can cause problems when the dynamic linker does
not ignore the target libraries but tries to load them instead. This
happens for example when building on x86_64-musl for aarch64-musl.
Add named config profiles.
This adds support for named config profiles. Previously, only `dev` and `release` were allowed in config files, it now supports all profile names. I think it would be strange to have arbitrarily named profiles in `Cargo.toml`, but not allow them in config. This is a deviation from the RFC, but RFC 2282 was written before named profiles which I think changes the landscape.
This diff is a little large due to some refactoring to make it work well. Overview of the changes:
- Removed `ProfileKind` and only use an `InternedString` to track the name of the profile. I didn't feel like the enum carried its cognitive weight, and it seems to simplify some things.
- `Profiles` is no longer stored in the manifest. There was no need to do a bunch of processing for each manifest. `Manifest` now only retains the low-level `TomlProfiles`. A single `Profiles` now lives in `BuildContext`.
- The profile name requested by the user is no longer passed around. It is given to `Profiles::new` and retained inside `Profiles`.
- `Profiles::get_profile` no longer follows the priority stack and inheritance each time a profile is requested. Instead, the profile is computed once (in `Profile::new`) and merged into a single profile. This simplifies getting a profile, and makes it easier to deal with getting the config values in one place.
- I switched profile names to be `InternedString` instead of `String`. There's not a strong reason to do this, other than it seemed a little strange to be creating lots of `String`s.
- I also added `PartialEq<str>` for `InternedString`. It has come up a few times in the past, and it seems useful. I'm not sure if it was excluded intentionally?
- The validation that the profile exists is now done in one place (`Profiles::new`).
- I removed the back-compatibility for the `overrides` key (which was renamed to `package` back in October).
Notes:
- Some of the error messages aren't as good as before, because they don't tell you where the error is located (`Cargo.toml` or `.cargo/config`). This is because the location data is lost by the time validation is done. Hopefully it will be obvious from the profile name and error message. I tried to improve error messages wherever I could.
- There are more calls to `clone()` than I would like, but they are kinda hard to avoid. Should be fewer than before.
- I noticed a bug with `-Zpanic-abort-tests` not supporting named profiles. I'll fix that separately.
- I think this fixes some bugs where package overrides in config weren't merging properly with package overrides defined in `Cargo.toml`.
Rename `Kind`
Rename `dependency::Kind` → `dependency::DepKind`
Rename `source_id::Kind` → `source_id::SourceKind`
I struggle when there are multiple types with the same name in the same code base. I think this makes it a little clearer what the type is.
I was tempted to also rename `registry::Kind`, but I could not think of a good name. That file is particularly hard for me to understand (locked vs normal sources, abstract trait, etc.), so I don't feel comfortable changing it. It's also localized in one file, so not as important.
There's an existing bug (#7782) in Cargo which exacerbates the issue
here but in general having a stack of errors is a bit easier to read and
work with than having a big long error message.
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
Migrate from the `failure` crate to `anyhow`
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.
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.
Fix several needless_borrow clippy lints.
Fixes several [needless_borrow](https://rust-lang.github.io/rust-clippy/v0.0.212/index.html#needless_borrow) clippy lints.
I've only fixed this kind of lint errors and not others, since for some reason these are the only ones that show as red squigglies in my editor of choice.
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 dynamic linking for Windows UWP MSVC targets
When creating a dynamic library, the MSVC linker generates an import library (.lib) next to the .dll file. Cargo has explicit knowledge of this and includes those generated .dll.lib on the list of files generated by a Cargo invocation.
However, the check to see if those import libraries must be included is too strict and doesn't match any Windows targets that don't end in `pc-windows-msvc`. For example, https://github.com/rust-lang/rust/pull/63155 added several new Windows targets for targeting UWP called `*-uwp-windows-msvc`. The end result is that the sysroot for these UWP toolchains don't contain a `std-XXX.dll.lib` file and thus any executable that uses `-C prefer-dynamic` will fail to link because the `std` library is not linked at all.
This change relaxes the test and makes Cargo know about those import libraries for all Windows MSVC targets.
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.
