fix: Don't try to un-archive ar files for hashing

[Xuanwo]

Fix #1250

Thanks for @alex's repro, this PR fixed this issue by removing the un-archive logic of AR files.

I believe this issue could be reproduced by put any ar files like the following for sccache (which ar can't handle):

ossl/lib/libssl.a: Mach-O universal binary with 2 architectures: [x86_64:\012- current ar archive random library] [\012- arm64:\012- current ar archive random library]

[alex]

Is it a problem to remove the ar handling for timestamps on macOS? If yes, do we need to make this code universal-archive aware? https://github.com/rust-lang/rust/blob/master/compiler/rustc_codegen_ssa/src/back/archive.rs#L176-L183 is some code I wrote for rustc to process them.

[Xuanwo]

Is it a problem to remove the ar handling for timestamps on macOS?

Based on my current understanding, the worst-case scenario is a cache miss when the timestamps are different, which I consider acceptable.

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: +0.06 🎉

Comparison is base (1c6ec75) 29.37% compared to head (1cdcab1) 29.43%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1773      +/-   ##
==========================================
+ Coverage   29.37%   29.43%   +0.06%     
==========================================
  Files          49       49              
  Lines       17626    17616      -10     
  Branches     8507     8501       -6     
==========================================
+ Hits         5177     5185       +8     
+ Misses       7357     7341      -16     
+ Partials     5092     5090       -2     

Impacted Files	Coverage Δ
src/compiler/rust.rs	32.76% <0.00%> (+0.15%)	⬆️
src/lib.rs	5.47% <0.00%> (+0.05%)	⬆️
src/server.rs	32.23% <0.00%> (-0.42%)	⬇️
src/util.rs	22.38% <0.00%> (-1.22%)	⬇️

... and 11 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[drahnr]

I'd prefer to keep the logic as is, but fallback on the hash in case ? takes effect, such that the hash of the entire file is used. That way we can preserve behavior as is for anything non-mac

[Xuanwo]

I believe this could lead to increasingly delicate and intricate behavior. I suggest removing this logic entirely unless someone wishes to provide a correct implementation.

[drahnr]

What are the consequences of removing it entirely? The timestamps are still present so on mac os we get (according to the comment) no cache hits for ar files at all. How many ar-format files are present in an average compilation run C/C++/rust? With that information we could make a more informed choice what is worth it. We can merge the change in the meantime, to avoid breakage at the potential cost of efficiency, but the topic should be followed up + tracked in an issue. Just deleting it is not solving it.

[Xuanwo]

Hi, I add a TODO notes here for hash_all_archives which explains what happened here. PTAL.

[alex]

I've created #1776, which uses object to handle fat archives.

[sylvestre]

it needs rebasing, could you please have a look?

[drahnr]

I think it is obsolete with the merge of #1776 iiuc

[Xuanwo]

Replaced by #1776, closing now. Thanks @alex for the better solution!