--emit=metadata emitting empty .rmeta file

[0dvictor]

At present, rustc --emit=metadata foo.rs generates an empty rmeta file named libfoo.rmeta. The logic behind is that rmeta is not needed for certain crate types. However, I feel we should still save it to a file when user explicitly requested it by --emit=metadata, especially the metadata is always available in memory regardless of output crate types.

[ehuss]

I would be cautious with this, as it could be a noticeable increase in disk usage for some projects. Rust already uses too much disk space. There should probably be a stronger reason than "it seems like it should".

[bjorn3]

Emitting an empty .rmeta file makes sense, as the metadata is what is needed to use it with --extern/extern crate. For executables, cdylibs and staticlibs that is impossible, so no metadata is needed in those cases.

[0dvictor]

There should probably be a stronger reason than "it seems like it should".

Definitely. IMO, user's explicit request should be honored; therefore, in this case, the explicit request is ---emit=metadata.

On the other side, I agree with @bjorn3 's point that the metadata is not needed for certain crate types; however, under this scenario, I feel rustc should print an error or warning message instead of silently generating an empty file.

[0dvictor]

it could be a noticeable increase in disk usage for some projects

Does it mean these projects request --emit=metadata with crate types that do not need metadata? If it does, is there any obstacles or restrictions that these project cannot remove --emit=metadata from the arguments?

[bjorn3]

Does cargo check use --emit=metadata for executables?

[ehuss]

Does it mean these projects request --emit=metadata with crate types that do not need metadata?

Yes. this is how cargo check works.

[jyn514]

Why is cargo passing --emit=metadata for these crate types? It knows already that it's not passing crate-type=lib, it can omit the metadata flag in that case.