DirectorySourceOptions is marked as #[non_exhaustive], and only
exposes the Default trait, so we need to instantiate a mutable
instance using default(), and then change tpl_extension to the
value we want.
Add more metadata to `rustc_fingerprint`
Previously, `rustc_fingerprint` was only using the path and mtime for each executable, but this is not always sufficient. For example, Fedora will [clamp mtimes] to help reproducible builds, so Rust 1.82 looks like `/usr/bin/rustc` and `2024-10-17 00:00:00` across all builds in Fedora 39 through 42 (rawhide), even though they are different in their full version strings, LLVM, etc.
[clamp mtimes]: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
If the target directory (including `.rustc_info.json`) is shared across such systems, the fingerprint wouldn't notice the difference, and cargo would try to use artifacts that aren't actually compatible, like:
```
error[E0514]: found crate `autocfg` compiled by an incompatible version of rustc
--> build.rs:2:14
|
2 | let ac = autocfg::new();
| ^^^^^^^
|
= note: the following crate versions were found:
crate `autocfg` compiled by rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc42): [...]/target/debug/deps/libautocfg-589c41db1eea6297.rlib
= help: please recompile that crate using this compiler (rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc40)) (consider running `cargo clean` first)
```
We can improve this situation by adding the file length, although that could also happen to be the same, and the creation date that will match when the file was installed, though not all filesystems support that. All of this comes from a single metadata call, so it shouldn't have any noticeable slowdown that would hurt the caching effort.
chore(deps): update rust crate security-framework to v3
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [security-framework](https://lib.rs/crates/security_framework) ([source](https://redirect.github.com/kornelski/rust-security-framework)) | workspace.dependencies | major | `2.11.1` -> `3.0.0` |
---
### Release Notes
<details>
<summary>kornelski/rust-security-framework (security-framework)</summary>
### [`v3.0.0`](https://redirect.github.com/kornelski/rust-security-framework/compare/v2.11.1...v3.0.0)
[Compare Source](https://redirect.github.com/kornelski/rust-security-framework/compare/v2.11.1...v3.0.0)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC4xMzUuMiIsInVwZGF0ZWRJblZlciI6IjM4LjEzNS4yIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbXX0=-->
fix(util): Respect all `..`s in `normalize_path`
### What does this PR try to resolve?
The fact that `normalize_path` was only designed for absolute paths bit us when working out #14497 and so I decided to make sure it worked. The other alternative I considered was having it assert that the path was absolute.
Since I did try out the assert and Cargo tests hit it, this likely fixes something but I haven't dug through to be able to say what.
### How should we test and review this PR?
### Additional information
Previously, `rustc_fingerprint` was only using the path and mtime for
each executable, but this is not always sufficient. For example, Fedora
will [clamp mtimes] to help reproducible builds, so Rust 1.82 looks like
`/usr/bin/rustc` and `2024-10-17 00:00:00` across all builds in Fedora
39 through 42 (rawhide), even though they are different in their full
version strings, LLVM, etc.
[clamp mtimes]: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
If the target directory (including `.rustc_info.json`) is shared across
such systems, the fingerprint wouldn't notice the difference, and cargo
would try to use artifacts that aren't actually compatible, like:
```
error[E0514]: found crate `autocfg` compiled by an incompatible version of rustc
--> build.rs:2:14
|
2 | let ac = autocfg::new();
| ^^^^^^^
|
= note: the following crate versions were found:
crate `autocfg` compiled by rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc42): [...]/target/debug/deps/libautocfg-589c41db1eea6297.rlib
= help: please recompile that crate using this compiler (rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc40)) (consider running `cargo clean` first)
```
We can improve this situation by adding the file length, although that
could also happen to be the same, and the creation date that will match
when the file was installed, though not all filesystems support that.
All of this comes from a single metadata call, so it shouldn't have any
noticeable slowdown that would hurt the caching effort.
refactor(test): Remove dead 'expect_stdout_contains_n' check
### What does this PR try to resolve?
This was missed when removing the assert
This is part of #14039
### How should we test and review this PR?
### Additional information
add unstable -Zroot-dir flag to configure the path from which rustc should be invoked
This implements the proposal described [here](https://github.com/rust-lang/cargo/issues/9887#issuecomment-2273742881): we add a new flag, for now called `-Zroot-dir`, that configures the directory relative to which rustc is given the crate root filenames to build. (Files outside this directory are passed absolutely.)
This is necessary to be able to fix (no github don't close that issue yet) https://github.com/rust-lang/rust/issues/128726: in multi-workspace repositories that use scripts to manage a whole bunch of cargo invocations, currently the output cargo+rustc produce is often hard or even impossible to interpret for both human and machine consumption. This is because directories in the output are always relative to the workspace root, but when cargo is invoked many times for different workspaces, it is quite unclear what the workspace root is for the invocation that failed.
So I suggest we should have a new flag that the build script in such a repo can set to the consistent "root dir" that the user would recognize as such (e.g., the root of the rustc source tree), and all paths emitted by cargo and rustc should be relative to that directory.
I don't know all the places that cargo itself emits paths (if any), but this PR changes the way we invoke rustc to honor the new flag, so all paths emitted by rustc will be relative to the `-Zroot-dir`.
See https://github.com/rust-lang/rust/pull/132390 for the changes needed in rustc bootstrap to wire this up; together, that suffices to finally properly show errors in RA for all parts of the rustc src tree. :)
docs(resolver): Further v3 prep
### What does this PR try to resolve?
This is a follow up to #14725
### How should we test and review this PR?
### Additional information
fix: track version in fingerprint dep-info files
### What does this PR try to resolve?
Encodes the version information into Cargo's fingerprint dep-info files,
so that when the format encoding changes in the future,
Cargo understands a dep-info file was outdated and doesn't bother parsing it.
Since there was no version info encoded in the old format (call it v0),
to be compatible with older cargoes,
this PR works around it with a horrible hack.
It is explained in the doc comment of `EncodedDepInfo`.
### How should we test and review this PR?
This PR also adds a static file which is v0 depinfo,
to ensure newer cargoes give up parsing it successfully without allocation errors.
See the allocation failures in this CI job result: https://github.com/weihanglo/cargo/actions/runs/11601065840/job/32302943597
It is no harm to keep the v0 test file also fine with removing it from git.
### Additional information
Fixesrust-lang/cargo#14712
test: Remove unused msrv-policy
### What does this PR try to resolve?
Missed this in #14639
### How should we test and review this PR?
### Additional information
Encodes the version information into Cargo's fingerprint dep-info files,
so that when the format encoding changes in the future,
Cargo understands a dep-info file was outdated and doesn't bother parsing it.
Since there was no version info encoded in the old format (call it v0),
to be compatible with older cargoes,
this PR works around it with a horrible hack.
It is explained in the doc comment of `EncodedDepInfo`.
download targeted transitive deps of with artifact deps' target platform
### What does this PR try to resolve?
Fixes#12554. `download_accessible` will now download platform-specified deps of artifact deps with `target = ...`.
It will also resolve the panic in `cargo tree -Z bindeps` in [#10593 (comment)](https://github.com/rust-lang/cargo/issues/10593#issuecomment-1317759526), where:
- a dependency of an artifact dependency is platform specified
- artifact dep itself is { target = } with the same platform as its own dependency
- the platform is not activated.
Essentially, `no entry found for key` was happening because for artifact deps with `{.., target = <target>}`, transitive deps that specified their platform as `<target>` were not downloaded. This is why adding `--target all` to `cargo tree -Z bindeps` made the bug dissapear.
### How should we test and review this PR?
Tests included in this PR should be enough.
~~Test `artifact_dep::proc_macro_in_artifact_dep` still throws; this PR will be ready for review once the test does not panic.~~
### Additional Information
`used` set needs to be target-aware
r? `@weihanglo`
Remove requirement for --target when invoking Cargo with -Zbuild-std
This PR addresses [this issue](https://github.com/rust-lang/wg-cargo-std-aware/issues/25) re: build-std stabilization. We believe the requirement for --target to be specified when invoking cargo with -Zbuild-std, from our testing, is no longer needed. Now, with this change, by default Cargo will use the Host CompileKind, rather than a manually specified CompileTarget. We propose removing this restriction in order to test this more widely. Our own testing is detailed below.
This change has been tested in the following manner:
* Building crates depending on proc_macro, std, and build scripts (which themselves depend on proc_macro)
* Various RUSTFLAGS, such as `-Zsanitizer=cfi`, `-Cembed-bitcode=yes`, `-Cforce-frame-pointers`, `-Cforce-unwind-tables=yes`, `-Csoft-float=yes`, `-Zbranch-protection=pac-ret`.
docs(fingerprint): document the encoding of Cargo's depinfo
### What does this PR try to resolve?
When investigating rust-lang/cargo#14712,
I figured that it lacks of docs for the Cargo's depinfo format.
Hence documenting them.
This PR also move dep info files related items to a separate module.
### How should we test and review this PR?
No behavior change, though I may submit a hack of #14712 after this.
I didn't move dep-info specific documentation into that new module.
It feels more nature for keeping them all in the fingerprint module.
Allow build scripts to report error messages through `cargo::error`
Adds the `cargo::error` build script directive. It is similar to `cargo::warning`, but it emits an error message and it also fails the build.
This is a repost of #14435 with the tests updated, a note added to the documentation about using this in a library, and updating the MSRV.
Closes#10159
fix(publish): Downgrade version-exists error to warning on dry-run
### What does this PR try to resolve?
Especially for beta, this was the most conservative, minimal change.
Fixes#14721
### How should we test and review this PR?
### Additional information
This will get cherry-picked to beta
