Don't rely on mtime to test changes
### What does this PR try to resolve?
Fixes#13139 by making sure tests aren't relying on changing the mtime alone
### How should we test and review this PR?
The pattern to watch out for is when a file is created with empty contents, e.g. `.file("foo", "")`, then later the same file updated with empty contents, e.g. `.change_file("foo", "")`. Tests should be making an actual change to the contents.
refactor: Pull PackageIdSpec into schema
### What does this PR try to resolve?
This removes one of the remaining ties `util_schemas` has on the rest of cargo as part of #12801.
### How should we test and review this PR?
This is broken up into small commits
### Additional information
In https://github.com/rust-lang/rust/blob/87e1447aa/compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs#L856
when the remap result of `work_dir` is an empty string,
LLVM won't generate some symbols for root debuginfo node.
For example, `N_SO` and `N_OSO` on macOS,
or `DW_AT_comp_dir` on Linux when debuginfo is splitted.
Precisely, it is observed that when the `DIFile` of compile unit was
provied with an empty compilation `Directory` string,
LLVM would not emit those symbols for the root DI node.
This behavior is not desired,
resulting in corrupted debuginfo and degrading debugging experience.
This is might not be a bug of `--remap-path-prefix` in rustc,
since `-fdebug-prefix-map` in clang 16 could have the same result
(`DW_AT_comp_dir` is gone when `work_dir` is remapped to an empty string).
However, in gcc 12 `fdebug-prefix-map` will return an absolute work_dir
when an empty string occurs.
To not bother whether this needs to be fixed in rustc or not,
let's fix it by always appending an explicit `.`
when `--remap-path-prefix` remaps to relative workspace root
a.k.a. where rustc is invoking.
For more on gcc/clang remap options, see
https://reproducible-builds.org/docs/build-path/
fix: Print rustc messages colored on wincon
### What does this PR try to resolve?
The real fix is over in rust-cli/anstyle#150; this just upgrades to it
Fixes#13104
### How should we test and review this PR?
I hacked vt console support off, ran a build before and rustc messages weren't colored. Now with this change, rustc messages are colored.
### Additional information
This still doesn't address why wincon is being used on their system
Add a windows manifest file
This adds a Windows [application manifest file](https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests) to the built `cargo.exe` for windows msvc. This manifest file is used to enable modern features of Windows. [`rustc`](7df0c211ac/compiler/rustc) has been using a similar manifest for about a year now.
The manifest file does the following:
* States our compatibility with Windows versions 7, 8, 8.1, 10 and 11. This allows avoiding unnecessary compatibility shims.
* Sets the code page to UTF-8. This should have no real impact on existing code (which should work with any code page). That said it may avoid issues if dependencies do use the local code page because conversions to/from Unicode are lossy so if a Unicode code point has no local code page equivalent, information is lost.
* Enable long path awareness. Mostly rust itself side-steps long path issues by using `\\?\` paths internally. However, this doesn't work for the current directory whereas using this option does.
You can test that a manifest file has been embedded by extracting it to a new file:
mt -nologo -inputresource:cargo.exe -out:embedded.manifest
You can also examine the `.rsrc` (aka resource) section using `dumpbin`
dumpbin /SECTION:.rsrc /ALL cargo.exe
### Additional info
This also sets the [`/Wx` linker option](https://learn.microsoft.com/en-us/cpp/build/reference/wx-treat-linker-warnings-as-errors?view=msvc-170) which turns linker warnings into errors. When setting linker options manually, I prefer to also set this because, unless there are also linker errors, `rustc` will not show linker warnings by default. Linker warnings should be rare and usually do indicate an actual problem so not ignoring them should be fine.
Avoid writing CACHEDIR.TAG if it already exists
Cargo currently unconditionally writes `CACHEDIR.TAG` files even if they already exist.
This practice causes problems for build systems that disallow multiple writes to the same file.
re-enable flaky tests thanks to update to `gix-config`. (#11821)
Related to #11821.
With `gix-config` now being fixed, it will properly respect `GIT_CONFIG_NOSYSTEM` both for system-wide configuration as well as for the git installation configuration.
That way, credential helpers provided by the git installation won't be called anymore, which prevents them from 'somehow' emitting information to stderr.
The latter was previously disabled for credential helpers, and despite [everything looking like it should work][1], it simply didn't.
[1]: https://github.com/rust-lang/cargo/pull/13117#issuecomment-1844881287
fix bash completion in directory with spaces
### What does this PR try to resolve?
This PR fixes bash completion for `cargo run --bin <TAB>` when the path to the project contains a space.
### How should we test and review this PR?
1. create a project in a directory with a space, for example `mkdir '/tmp/has space' && cd '/tmp/has space' && cargo new foo && cd foo`.
2. add a binary to Cargo.toml, e.g.
```
[[bin]]
name = "bar"
```
3. on bash, type `cargo run --bin b` and press tab
4. observe error message `bash: $manifest: ambiguous redirect`, command is not completed
5. apply the fix to `$(rustc --print sysroot)/etc/bash_completion.d/cargo`
6. repeat step 3 and observe that the command is completed successfully
With `gix-config` now being fixed, it will properly respect `GIT_CONFIG_NOSYSTEM`
both for system-wide configuration as well as for the git installation configuration.
That way, credential helpers provided by the git installation won't be called anymore,
which prevents them from 'somehow' emitting information to stderr.
The latter was previously disabled for credential helpers, and despite
everything^1 looking like it should work, it simply didn't.
[1]: https://github.com/rust-lang/cargo/pull/13117#issuecomment-1844881287
fix(toml): Disallow inheriting of dependency public status
### What does this PR try to resolve?
This is a step towards rust-lang/rust#44663. When discussing inheriting this field
for #13046, we realized that we should probably start by disallowing
inheritance. We can always add it later. imo the principle of what should
be inherited is what is truely common among dependencies. For example,
we don't allow removing features. Public should not be universally
applied and likely should be explicit so its not over-done, especially
since we can't (atm) lint for when a public dependency could be
non-public.
### How should we test and review this PR?
### Additional information
This reverts parts of #12817
This is a step towards moving `PackageIdSpec` into `schema` as manifests
need it as part of #12801.
While I didn't take this approach in #13080, that was largely how core
these functions are / how pervasive their use is.
re-enable previously disabled tests with Windows-specific fix
Related to #11821 for which this is a fix.
However, it's probably not yet the optimal solution, depending on how `stderr` of subprocesses should be handled.
### Tasks
* [x] try to fix the issue with an env var.
- Failure, as one warning remains that seems to originate from a C# HTTP client
* [x] figure out if `stderr` should be on or off by default - on by default like before, but now one can control it.
* [x] create a new `gix` release and use it here
### Review Notes
* Personally, I think `cargo` should keep `stderr` to be inherited so users can see potentially relevant warnings or errors provided by credential helpers. Thus this is still the default, but the tests that need it explicitly disabled `stderr` of credential helpers.
----
On Windows, `gix` will call the `git-credential-manager, but with
`stderr` set to `inherit` which makes any errors visible to the user,
just like `git` does.
```
1 1 Updating git repository `https://foo.bar/foo/bar`
2 +warning: auto-detection of host provider took too long (>2000ms)
3 +warning: see https://aka.ms/gcm/autodetect for more information.
4 +fatal: A task was canceled.
5 +warning: auto-detection of host provider took too long (>2000ms)
6 +warning: see https://aka.ms/gcm/autodetect for more information.`
````
This, however, isn't what's desirable in tests sometimes, nor may
it be desirable in Cargo.
For now, it seems easiest to disable this particular feature that
issues the warning messages, even though a future `gix` update
should allow to control what to do with `stderr`.
On Windows, `gix` will call the `git-credential-manager, but with
`stderr` set to `inherit` it makes any errors visible to the user,
just like `git` does.
```
1 1 Updating git repository `https://foo.bar/foo/bar`
2 +warning: auto-detection of host provider took too long (>2000ms)
3 +warning: see https://aka.ms/gcm/autodetect for more information.
4 +fatal: A task was canceled.
5 +warning: auto-detection of host provider took too long (>2000ms)
6 +warning: see https://aka.ms/gcm/autodetect for more information.`
````
This, however, isn't what's desirable in tests sometimes, nor may
it be desirable in Cargo.
In the latest version of `gix`, it's possible to control `stderr`
which is now set on a per-test basis.
Also note that for `cargo` as a whole the default didn't change,
and stderr of spawned helper programs will remain visible in the
enclosing terminal.
refactor: Clarify PackageId constructor names
### What does this PR try to resolve?
From #13080
> I would love to see eithe rename this function or have a doc comment on it. It always puzzle me what pure means.
From my experience, `new` is more normally a name for more direct construction when there are alternatives
### How should we test and review this PR?
### Additional information
feat(spec): Extend PackageIdSpec with source kind + git ref for unambiguous specs
### What does this PR try to resolve?
This tries to add just enough information to Package ID Specs that we can be sure they are unambiguous. On its own thats important but this will unblock #12914 so we can have a user-facing ID that can be used with cargo's CLI.
More specifically, this adds
- `git+`, etc prefixes to the scheme
- These were previously stabilized for `cargo metadata`s source id urls
- Like with `SourceID`, this will allow `PackageIDSpec` to generate `directory+` and `local-registry+` prefixes but not parse them. I'm assuming that the layers where those are dealt with they won't appear here but I don't have enough experience with them
- git ref query strings for URLs
Things from `SourceID` that this does not include
- precise: this seems less related to matching (e.g. ignored for `impl Ord for SourceId`)
- canonical URL for git kinds: this could be nice for users but users aren't the target audience and we can switch to these later
Fixes#10256
### How should we test and review this PR?
Per-commit
### Additional information
This is a step towards #44663. When discussing inheriting this field
for #13046, we realized that we should probably start by disallowing
inheritance. We can always add it later. imo the principle of what should
be inherited is what is truely common among dependencies. For example,
we don't allow removing features. Public should not be universally
applied and likely should be explicit so its not over-done, especially
since we can't (atm) lint for when a public dependency could be
non-public.
This reverts parts of #12817
refactor(schemas): Pull out mod for proposed schemas package
Originally for #12801 we talked about a `cargo-util-manifest-schema` package
- `util` in the name to not clash with plugins
- manifest specific to keep the scope down
The problem is we have types that aren't manifest specific, like
- `PartialVersion` (currently slated for `cargo-util-semverext`)
- `RustVersion`
- `PackageIdSpec`
- `SourceKind` (soon)
Things get messy if we try to break things down into common packages. Instead, I think it'd be useful to have a schemas package that has mods for each type of schema, re-exporting what is needed.
Normally, componentizing your package by the layer in the stack is a recipe for pain.
I don't think that'll apply here because these are meant to be so low level.
The other big concern could be compile times. My hope is it won't be too bad.
So this moves the `util/toml` types into the module and we can add more in the future.
chore(test): remove unnecesary packages and versions for `optionals` tests
### What does this PR try to resolve?
This PR was inspired by https://github.com/rust-lang/cargo/pull/13046#discussion_r1406387864 and https://github.com/rust-lang/cargo/pull/12189.
There is unnecessary to keep more pacakages and versions on test case and the more pacakage added, the more test time and CI resource taken up.
And this PR also fixed a issue that `overwrite_optional_with_optional` had not been added to `tests/testsuite/cargo_add/mod.rs`.
### How should we test and review this PR?
### Additional information
chore(config): migrate renovate config
[](https://renovatebot.com)
The Renovate config in this repository needs migrating. Typically this is because one or more configuration options you are using have been renamed.
You don't need to merge this PR right away, because Renovate will continue to migrate these fields internally each time it runs. But later some of these fields may be fully deprecated and the migrations removed. So it's a good idea to merge this migration PR soon.
#### [PLEASE NOTE](https://docs.renovatebot.com/configuration-options#configmigration): JSON5 config file migrated! All comments & trailing commas were removed.
🔕 **Ignore**: Close this PR and you won't be reminded about config migration again, but one day your current config may no longer be valid.
❓ Got questions? Does something look wrong to you? Please don't hesitate to [request help here](https://togithub.com/renovatebot/renovate/discussions).
---
This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/rust-lang/cargo).
This is more robust than `thread::sleep`, ensuring
* foo is running before the first `cargo uninstall` call
* foo is stopped before the second `cargo uninstall` call
test(mdman): Switch to snapbox
Working with #13090 is the motivation
Benefits
- We use it elsewhere
- We don't have to bake in our own snapshotting solution
- It is more obvious how to update the snapshots
Include declared list of features in fingerprint for `-Zcheck-cfg`
This PR include the declared list of features in fingerprint for `-Zcheck-cfg` (#10554)
`--check-cfg` verifies that `#[cfg()]` attributes are valid in Rust code, which includes `--cfg features foo` definitions that came from `[features]` tables in `Cargo.toml`. For us to correctly re-check cfgs on feature changes,we need to include them in the fingerprint.
For example, if a user deletes an entry from `[features]`, they should then get warnings about any `#[cfg()]` attributes left in the code. Without this change, that won't happen. With this change, it now does.
