rust: workaround --print file-names emitting staticlibs / dylibs.

[emilio]

This fixes cargo check in mozilla-central. The issue is that rustc --print
file-names emits a somewhat poor approximation of what's actually going to be
emitted.

So for a staticlib crate, it will also print the staticlib file, which is not
great.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1612855#c2 for a more
straight-forward explanation of the failure case.

Sccache would try to find the library and fail, erroring as a consequence.

Pile up on the existing workaround for rmeta files not showing up
(rust-lang/rust#54852) by removing files that are not
metadata when we only request metadata.

rust-lang/rust#68799 contains a rust-side fix that would
also fix this.

[froydnj]

Thanks.

[froydnj]

I think we do have Rust version information at some point (maybe propagating it to here is hard), but maybe we should consider making this change conditional on the compiler version so that it's easy to detect regressions in the future?

[emilio]

I think we do have Rust version information at some point (maybe propagating it to here is hard), but maybe we should consider making this change conditional on the compiler version so that it's easy to detect regressions in the future?

This works regardless of the other fix being in rust or not... Not sure what a condition for this workaround would look like.

[froydnj]

I think we do have Rust version information at some point (maybe propagating it to here is hard), but maybe we should consider making this change conditional on the compiler version so that it's easy to detect regressions in the future?

This works regardless of the other fix being in rust or not... Not sure what a condition for this workaround would look like.

I meant that if rustc_version >= fixed_rustc_version, we would not apply the workaround. It probably doesn't matter that much, but it would help people detect if rustc suddenly broke again.

[emilio]

Ah, that's fair... We'd need to fix rustc first though :P