This was allowed when switching from `toml` v0.5 to `toml_edit` which
started allowing empty keys when parsing TOML.
This mirrors the change
we made for disallowing empty feature names in #12928.
`all-static` feature should include `vendored-libgit2`
Cargo has an `all-static` feature which is supposed to statically link dependencies for distributing.
However, it doesn't include `libgit2`. If the system has a compatible version of `libgit2` and `pkg-config` installed, then the `all-static` build will still use the system `libgit2`.
refactor(schema): Remove reliance on cargo types
### What does this PR try to resolve?
This is another step towards #12801.
The only thing left is `validate_package_name` which I left out because I want to explore ways of handing that and don't want this commit blocked on it
### How should we test and review this PR?
### Additional information
fix(toml)!: Disallow `[lints]` in virtual workspaces
This was missed with the initial `[lints]` implementation.
While this is a breaking change, this is aligned with ones we've done in the past. A lot of times, we warn first. My hope is that isn't needed this time because
- It only exists virtual workspaces so they aren't published
- It is a nop to have this which is likely to be caught
- This is so new that the number of people using it, and likely running into this case, is quite low.
This was missed with the initial `[lints]` implementation.
While this is a breaking change, this is aligned with ones we've done in
the past. A lot of times, we warn first. My hope is that isn't needed
this time because
- It only exists virtual workspaces so they aren't published
- It is a nop to have this which is likely to be caught
- This is so new that the number of people using it, and likely running
into this case, is quite low.
Limit exported-private-dependencies lints to libraries
### What does this PR try to resolve?
Completed https://github.com/rust-lang/cargo/issues/13039.
This PR limit `exported-private-dependencies` lint in libraray `Target`.
### How should we test and review this PR?
Your can checkout out 2348ac2a20edf772495349d7911938251e343bf1 and run test, it will failed and then it will be passed in the commit 2348ac2a20edf772495349d7911938251e343bf1
### Additional information
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.
