Skip to content

rustc --print file-names wrongly prints .rlib for --emit=metadata #54852

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Marwes opened this issue Oct 5, 2018 · 2 comments
Open

rustc --print file-names wrongly prints .rlib for --emit=metadata #54852

Marwes opened this issue Oct 5, 2018 · 2 comments
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Marwes
Copy link
Contributor

Marwes commented Oct 5, 2018

For sccache to cache rustc builds it uses rustc --print file-names to figure out which files get emitted so it cache them for later. For --emit metadata builds it appears that rustc prints that it would emit a .rlib file which seems to be false, only .rmeta files get emitted.

Trying to find out where this happens but so far no luck (it might actually be correct behavior and the fix should be in sccache).

See mozilla/sccache#301 (comment)

@jonas-schievink jonas-schievink added A-driver Area: rustc_driver that ties everything together into the `rustc` compiler T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. labels Jan 27, 2019
@luser
Copy link
Contributor

luser commented May 28, 2019

cargo nightly will now invoke rustc with --emit=dep-info,metadata,link, but running rustc --emit=dep-info,metadata,link --print=file-names still doesn't print the rmeta name, which isn't good.

emilio added a commit to emilio/sccache that referenced this issue Feb 3, 2020
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 pushed a commit to mozilla/sccache that referenced this issue Feb 3, 2020
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.
@Enselic
Copy link
Member

Enselic commented Nov 20, 2023

Triage: It seems to me as if --print file-names does what it says it does? It's documentation is:

  • file-names — The names of the files created by the link emit kind.

Note that it does not claim to print the name of the metadata file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants