fix(compiler): forward verbose flag to rustc for local crates

[raushan728]

Fixes #16531

This PR passes the --verbose flag down to rustc for local packages and tracks this verbosity state in the unit Fingerprint hash. Now, toggling the verbose flag properly invalidates the cache for the local crate, fetching the full, untruncated error directly from the compiler without rebuilding all dependencies.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ehuss, @epage, @weihanglo
• @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
• Random selection from ehuss, epage, weihanglo

[raushan728]

CI is failing on ~50 tests because the snapshots need to be updated with the new [DIRTY] state and --verbose flag.

Since SNAPSHOTS=overwrite removes the [..] wildcards and hardcodes local hashes, I held off on pushing the test updates. Let me know if this looks good, and should I manually fix the wildcards in the failing tests?

[epage]

tracks this verbosity state in the unit Fingerprint hash

From #16531 (comment)

So to summarize, the proposal is:

...

• When forwarded, include cargo's verbosity mode in either the Unit Hash (new cache entry) or the Fingerprint (overwrite existing cache entry)

There was a choice here and you went one route. Please when doing these types of things document your reasoning.

Note that the statement wasn't a commitment to do this but a re-iteration of the request to confirm understanding which brings us to #16531 (comment)

One of the concerns was around the output caching behavior. For some use cases, like the linker error described above, it should be fine since errors aren't cached. But for other cases, it can cause confusing behavior (like #8830 and #9003). My understanding is that rustc rarely emits verbose output, so in most cases it shouldn't be a problem. It's a small risk, and maybe it can be mitigated with documentation?

I think this is saying that we decided to punt on tracking this is in the hash or fingerprint. Looking at the notes doesn't provide any more insight.

@ehuss do you remember which way we landed on this?

[raushan728]

I went with fingerprint instead of unit hash because running with --verbose is usually a temporary one-off check. Using unit hash would duplicate artifacts and unnecessarily bloat the target/ directory. Fingerprint just forces a rebuild to show the full error without wasting space.

Regarding tracking it at all: if we don't dirty the cache, Cargo just replays the previously cached truncated message. So just forwarding the flag wouldn't actually show the full output.

To drop the fingerprint tracking entirely if @ehuss confirms we should punt on it.

[ehuss]

I don't recall if we landed one way or the other on caching.

Right now I don't have a good answer to that myself. The downsides seem clear to me:

• Not tracked: You won't get the verbose output (enabling -v when already cached), or the verbose output will be stuck "on" (removing -v after building). You have to know to run cargo clean if you really want to see the difference.
• Fingerprint-tracked: Just changing the -v flag will thrash your cache (and the majority of the time, the output will be identical).
• Unit-tracked: Switching -v can explode the build cache (and the majority of the time, the output will be identical).

These differences are not applicable to the linker error mentioned in the issue, since that wouldn't be cached. If we truly only care about that one message (or any messages with errors), then I would go with not-tracked (since an error isn't cached). That would be the least disruptive, and address the concern in the issue (not seeing the full linker output). The downside is that it wouldn't help with any rustc messages in the future that are not errors but change based on --verbose.

We could always change this in the future, too.

[raushan728]

Since errors (like the linker error) aren't cached anyway, going with the "Not tracked" solves the primary issue without thrashing the cache for successful builds.

I'll drop the fingerprint tracking, keep just the --verbose forwarding in prepare_rustc . I'll push the update shortly.