Skip to content
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

Add --emit=nothing to tell rustc not to emit any files (even if --crate-type=lib) #52661

Open
LukasKalbertodt opened this issue Jul 24, 2018 · 4 comments
Labels
A-driver Area: rustc_driver that ties everything together into the `rustc` compiler C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@LukasKalbertodt
Copy link
Member

In order to only check if a program is well-formed (think cargo check), one would like to call rustc without emitting any files. cargo check uses --emit=metadata -Z no-codegen because the metadata is needed to check dependent crates.

However, it seems like it's impossible to tell the compiler to not write any files in the case of --crate-type=lib. For the default --crate-type=bin it works: rustc -Z no-codegen foo.rs does not emit any files. But again, for rustc -Z no-codegen --crate-type=lib foo.rs it emits an .rlib file.

In case this isn't a bug, would it be possible to add an --emit=nothing or equivalent option?

(Related question on StackOverflow)

@leonardo-m
Copy link

See also Issue #50289

@nagisa
Copy link
Member

nagisa commented Jul 25, 2018

What would happen of one specified --emit=nothing,link,llvm-ir? What about --emit=link,llvm-ir,nothing?


The rlib file emitted with rustc -Z no-codegen --crate-type=lib foo.rs does not contain any machine code, only metadata (and so is equivalent to rmeta) which, again, would be necessary to check dependent crates.

@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-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jan 27, 2019
@dtolnay
Copy link
Member

dtolnay commented Aug 12, 2022

I would love to use this for build.rs feature detection, for example the stuff in https://github.com/dtolnay/anyhow/blob/d2c83e20a3b341946c502380e4230ff4e820ef32/build.rs.

Currently I use --emit=metadata but that does too much work. Testing on the serde crate, time rustc --crate-name serde --crate-type lib --emit=metadata serde/src/lib.rs takes 1.45 seconds while time rustc --crate-name serde --crate-type lib --emit=dep-info serde/src/lib.rs takes just 0.25 seconds, 6× faster, and still appears to do all the useful typechecking I need. However I am not comfortable switching build.rs from --emit=metadata over to --emit=dep-info because there is no reason --emit=dep-info would always need to do typechecking / trait solving. In the future a rustc optimization could make it not do what I need (while still emitting a dep-info file).

A typecheck-only emit mode, with no outputs other than diagnostics or json to stderr, would be great.

@dtolnay
Copy link
Member

dtolnay commented Aug 13, 2022

@nagisa:

What would happen if one specified --emit=nothing,link,llvm-ir? What about --emit=link,llvm-ir,nothing?

Counterproposal: instead of --emit=nothing, we should spell this as --emit=. The emit flag already takes a comma-separated list of outputs to produce. Today that list cannot be empty, or else it'll fail with the error message below. We just need to make the list allowed to be empty. That cleanly avoids needing to answer the meaning of nothing,link / link,nothing.

$ rustc --emit= src/main.rs

error: unknown emission type: `` - expected one of: `llvm-bc`, `asm`, `llvm-ir`, `mir`, `obj`, `metadata`, `link`, `dep-info`

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-feature-request Category: A feature request, i.e: not implemented / a PR. 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

5 participants