This adds the `-Z json-target-spec` CLI flag to assist with using custom
`.json` target spec files. `rustc` recently switched so that it requires
`-Z unstable-options` when using custom spec files
(https://github.com/rust-lang/rust/pull/151534). This can make it rather
awkward to use spec files with cargo because it then requires setting
RUSTFLAGS and RUSTDOCFLAGS to pass `-Zunstable-options`. It also ends up
causing some confusing error messages.
Now, using `--target` with `.json` extension files generates an error
that explains you need `-Zjson-target-spec`. The only thing this flag
does is disable that error, and automatically passes
`-Zunstable-options` with the `--target` flag.
This does not 100% cover json target spec files, because they can be
placed in RUST_TARGET_PATH or the sysroot, and `rustc` will
automatically search for them (without the `.json` extension in the
`--target` arg). The user will just need to use RUSTFLAGS/RUSTDOCFLAGS
in that situation (but I expect that to be rare).
The majority of this change is changing `CompileTarget::new` to take a
flag if `-Zjson-target-spec` is enabled, and then threading through all
the places that call it. `CompileTarget::new` is responsible for
generating an error if json is used without the Z flag.
### What does this PR try to resolve?
This PR adds a regression test to ensure that `cargo build
--artifact-dir` is rejected on the stable channel unless `-Z
unstable-options` is used.
The behavior is already correct, but this test ensures it does not
regress in the future.
### How to test and review this PR?
Run the Cargo test suite:
```bash
cargo test --test testsuite artifact_dir::artifact_dir_rejected_on_stable
We've been seeing occasional failures on CI with these tests timing out.
I'm guessing that the runners are too overloaded and are unable to
complete the test within 1 second. This bumps up the timeout to 10s to
see if that will resolve the problem.
rust-lang/rust#149514 added a build.rs to libtest,
which affected how Cargo print status message
(build.rs built first so Cargo printed `Compiling` first)
Regarding lint naming:
- I didn't go with `non_kebab_case` because we had received
encouragement to be more specific than `non_camel_case` when
discussing this at the All Hands
- I went with `bin` rather than `bin_name` because the thing we are
ultimately linting is the binary file stem, not any specific field, and if
other fields end up contributing to the binary name, we should include
those, like
[bin.namefilename](https://doc.rust-lang.org/cargo/reference/unstable.html#different-binary-name)
or any potential [prefixes or suffixes](https://github.com/rust-lang/cargo/issues/1970)
Regarding the lint's look: I tried to make this look as much like rustc
as possible:
```
Checking cargo v0.95.0 (/home/epage/src/personal/cargo)
warning: function `Is_default_main` should have a snake case name
--> src/cargo/lints/rules/non_kebab_case_bin.rs:188:4
|
188 | fn Is_default_main(path: Option<&cargo_util_schemas::manifest::PathValue>) -> bool {
| ^^^^^^^^^^^^^^^ help: convert the identifier to snake case (notice the capitalization): `is_default_main`
|
= note: `#[warn(non_snake_case)]` (part of `#[warn(nonstandard_style)]`) on by default
```
Fixes#15586
### What does this PR try to resolve?
This is a follow-up for #16407.
This PR is supposed to make patch-related error messages closer to the
desired
[style](https://rustc-dev-guide.rust-lang.org/diagnostics.html#errors-and-lints),
remove unnecessary(?) context wrappings, and fix a few minor issues in
code.
I tried to restructure some of the error messages to include the values
from `.context()` where I thought it would make sense. Obvious
duplications (e.g. repository url of the patch) were removed.
I tried to rephrase some of the error messages to sound closer to the
desired style and to ease future migration to rustc's error reporter.
### How to test and review this PR?
Test changes should demonstrate the intended behavior change.
Suggestions on how to make messages even better are obviously welcome.
### Note
I was thinking about (and tried) moving this portion of error messages
directly to the annotate snippets
[#15944](https://github.com/rust-lang/cargo/issues/15944), but with
several functions returning `Result` it was not straightforward.
Probably needs well-thought refactoring, which is out of scope of this
PR.
r? @weihanglo
### What does this PR try to resolve?
In https://github.com/rust-lang/cargo/pull/16502#discussion_r2694115028
there was a discussion about merging the `build-script` and `deps` dirs
in the `build-dir`.
Currently:
```
build-dir/<profile>/build/<pkgname>/<hash>/
deps/ # rustc output
build-script/ # build script binary
build-script-execution/ # the output of running a build script
```
Note: For build-scripts `deps` is empty.
This PR:
1. moves the build script binaries from `build-script` to `deps` to
simplify the layout
2. renames `build-script-execution` to `build-script` to simplify the
dir naming and shorten the path length for windows
```
build-dir/<profile>/build/<pkgname>/<hash>/
deps/ # rustc output including build-script bins
build-script/ # the output of running a build script
```
cc tracking issue: https://github.com/rust-lang/cargo/issues/15010
### How to test and review this PR?
see the test changes
r? @epage
I mixed the `-Zno-embed-metadata` value into the general config hash,
because the flag does complicated stuff (pass rustc flag, but also
change how dependencies are passed to rustc).
Fixes: https://github.com/rust-lang/cargo/issues/16503
### Summary
Optimize cargo locate-project --workspace by adding a fast path that
avoids full workspace loading when possible.
### Problem
Previously, ```cargo locate-project --workspace``` always performed full
workspace loading, which includes:
Parsing all member manifests
Resolving path dependencies
Validating workspace configuration
This is expensive for large workspaces when all we need is the workspace
root path.
### Solution
Introduce a new function
```find_workspace_root_with_membership_check()``` that provides a fast
path by only reading the minimal set of manifests needed to determine
the workspace root.
### When Fast Path is Taken
The fast path succeeds when both conditions are met:
- The package is explicitly listed in ```workspace.members``` (including
glob patterns)
- The package is not excluded via workspace.exclude
Specific scenarios:
- Workspace root manifest: Returns immediately (the manifest is its own
workspace root)
- Explicit package.workspace pointer: Reads only the target workspace
manifest, verifies membership
- No explicit pointer: Walks up parent directories, checking each
Cargo.toml for membership
### When Slow Path is Taken
Falls back to full workspace loading when:
- Package is a member via path dependencies (implicit membership)
- Workspace has default-members defined (requires validation)
- Package is not found in explicit members list
- Any error occurs during fast path (ensures correct error messages)
Fixes#15107
This reverts https://github.com/rust-lang/cargo/pull/16489
though currently only compiler_builtins has link metadata
`-Zany-build-script-metadata` is not supported yet for build-std
This fix ensures the synthetic RunCustomBuild-RunCustomBuild edges carry
the manifest dep name, so `CARGO_DEP_*` environment variable uses the
correct prefix even with patched sources and renamed dependencies.
Resolves#16472
This diff adds the ability to specify a session ID when running `cargo
report timings` and `cargo report rebuilds`. Previously, these commands
always reported on the most recent build session. Now users can inspect
any previous session by passing `--id <SESSION_ID>`.