Add --filter-platform to `cargo metadata`.
This adds the `--filter-platform` flag to `cargo metadata` to give users a way to filter the resolve information based on the target triple.
This is just a prototype to open for feedback. Some things that need feedback:
- Debate the name of the flag.
- It uses "host" as a special triple to mean the local host. Does that make sense? It seemed a little weird.
- Should it also filter the dependencies in the "packages" array? Right now it only does resolve. I'm on the fence. It probably should, but that would be an intrusive change to rewrite the Package values.
- Should the filtering be transitive? That is, if a package is only reachable by a specific platform, should it be removed from the resolve "nodes"? What about "packages"? Currently it is included, with the intent that you walk the resolve starting with a root (like a workspace member). But it might be surprising to see "winapi" when you filter for a unix platform.
This will need documentation before it is merged.
Fix `cargo fix` not showing colors.
`cargo fix` runs `rustc` a final time after it has finished to:
- Show what happened if the fix failed.
- Show errors with `--broken-code`.
- Show any remaining warnings after a successful fix.
This last run was no longer showing colored diagnostics due to the stabilization of cache-messages. Cargo now unconditionally uses colored JSON messages, and then conditionally strips them after the fact. "cargo as rustc wrapper" was stripping the JSON flags which allowed Cargo to handle colors.
This fix works by putting the json flags back in for this final pass.
Add a note to discourage the use of -Zminimal-versions.
We've discussed this a few times, that the current implementation isn't working out, so let's be more transparent about it.
Fix profile override warning in a workspace.
Profile overrides would erroneously warn about unused packages in a workspace if the package was not being built. The fix here is to retain the `Resolve` for the entire workspace, and use that to determine the valid set of packages.
I think it would be good for a long-term goal to get rid of the second ("targeted") resolve. I'm still contemplating how a separate features resolver could achieve that, but it seems feasible long-term.
Closes#7378
Show better error message for Windows abnormal termination.
This helps display better error messages when there is an abnormal termination on Windows.
If rustc crashes, there was a slight mistake in #6270, where the error code was actually negative, so the message was getting hidden behind the `--verbose` flag. This changes it show that the abnormal error is always shown if rustc crashes in an unusual way.
This also changes `cargo test` to display a better message if the test crashes. Previously:
```
running 1 test
error: test failed, to rerun pass '--bin crash'
```
New:
```
running 1 test
error: test failed, to rerun pass '--bin crash'
Caused by:
process didn't exit successfully: `D:\Temp\crash\target\debug\deps\crash-b3c2389529da3d3e.exe` (exit code: 0xc0000374, STATUS_HEAP_CORRUPTION)
```
I didn't add any tests because testing on this on Windows seems a little precarious. AFAIK, the exact error message depends on the processor (like x86 vs i686), and Windows version. I was concerned about chasing down every little nuance, though I'm willing to try if it seems important.
Fixesrust-lang/rust#65692 (I think).
Use stricter -Z flag parsing.
This makes sure that toggle flags don't have any arguments (like `-Zno-index-update=foo`). It also provides slightly better error messages, like indicating which flag failed.
Set timestamp on generated files in archive to now
When generating files (Cargo.lock, Cargo.toml, and
.cargo_vcs_info.json), cargo neglected to set any timestamp on the file
in the archive. This results in them being created on disk with a
timestamp of 0 (Jan 1 1970 GMT) which is confusing another tool I use.
This patch alters the behavior to set the mtime to now.
Signed-off-by: Bruce Guenter <bruce@untroubled.org>
Support rustc's `-Z panic-abort-tests` in Cargo
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag
to the compiler itself will activate a mode in the `test` crate which
enables running tests even if they're compiled with `panic=abort`. It
effectively runs a test-per-process.
This commit brings the same support to Cargo, adding a `-Z
panic-abort-tests` flag to Cargo which allows building tests in
`panic=abort` mode. While I wanted to be sure to add support for this in
Cargo before we stabilize the flag in `rustc`, I don't actually know how
we're going to stabilize this here. Today Cargo will automatically
switch test targets to `panic=unwind`, and so if we actually were to
stabilize this flag then this configuration would break:
[profile.dev]
panic = 'abort'
In that case tests would be compiled with `panic=unwind` (due to how
profiles work today) which would clash with crates also being compiled
with `panic=abort`. I'm hopeful though that we can perhaps either figure
out a solution for this and maybe even integrate it with the ongoing
profiles work.
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag
to the compiler itself will activate a mode in the `test` crate which
enables running tests even if they're compiled with `panic=abort`. It
effectively runs a test-per-process.
This commit brings the same support to Cargo, adding a `-Z
panic-abort-tests` flag to Cargo which allows building tests in
`panic=abort` mode. While I wanted to be sure to add support for this in
Cargo before we stabilize the flag in `rustc`, I don't actually know how
we're going to stabilize this here. Today Cargo will automatically
switch test targets to `panic=unwind`, and so if we actually were to
stabilize this flag then this configuration would break:
[profile.dev]
panic = 'abort'
In that case tests would be compiled with `panic=unwind` (due to how
profiles work today) which would clash with crates also being compiled
with `panic=abort`. I'm hopeful though that we can perhaps either figure
out a solution for this and maybe even integrate it with the ongoing
profiles work.
rustfmt for nightly changes.
Something in the latest nightly versions of rustfmt has slightly changed the logic here. Fortunately stable ignores the new formatting, and it looks better to me anyways. I tend to always use nightly, so this helps me with a slight annoyance where this line keeps getting changed.
Allow --all-features in root of virtual workspace.
Accidentally restricted in #7507, pointed out by @hjmallon, `--all-features` flag is allowed in the root of a virtual workspace. Added a test to demonstrate its strange behavior.
For anyone that is curious, [this line](3a9abe3f06/src/cargo/ops/resolve.rs (L302)) is the code responsible for this behavior.
When generating files (Cargo.lock, Cargo.toml, and
.cargo_vcs_info.json), cargo neglected to set any timestamp on the file
in the archive. This results in them being created on disk with a
timestamp of 0 (Jan 1 1970 GMT) which is confusing another tool I use.
This patch alters the behavior to set the mtime to now.
Signed-off-by: Bruce Guenter <bruce@untroubled.org>
Reject feature flags in a virtual workspace.
This generates an error if feature flags are used in the root of a virtual workspace. Previously these flags were completely ignored. In the interest of avoiding confusion, I think it would be good to be explicit that these don't currently work. This could alternatively be a warning, but I think it is better to reject it outright.
cc #4753, #3620, #5015, #6195, etc.
