Respect -o output file in --print by dtolnay · Pull Request #110785 · rust-lang/rust (original) (raw)

Doesn't this break -o foo --emit=link --print native-static-libs? Both --emit=link and --print native-static-libs would be fighting over writing foo.

Good question. This PR does not apply to native-static-libs. That's handled differently from all the other --print options: --print normally means print to stdout, whereas --print=native-static-libs gets emitted via diagnostics machinery instead (sess.emit_note) to stderr, and continues to work that way after this PR. As far as I can tell the intended way to use native-static-libs is in combination with --error-format=json and then searching for a note with prefix "native-static-libs:" among the JSON messages.

So this PR does not break it or cause fighting over writing the same output file with multiple contents. native-static-libs will be inconsistent vs the other --print options by not respecting -o, but has always been inconsistent already, so I'm not sure it ends up being worse.

Maybe --print could be changed to allow explicitly specifying a path just like for --emit?

I am open to this. --print sysroot=sysroot.txt --print cfg=cfg.txt

I think -o makes sense to apply to --print regardless of whether --print KIND=PATH is supported. -o means "set a location for the output that was asked for". In rustc --emit=metadata -o PATH, the -o means set the location for the rmeta output. In rustc --emit=asm -o PATH, the -o means set the location for the asm output. In rustc --print=cfg -o PATH, the configuration data is the output being asked for, and I think -o should apply.

If --print + -o does get supported, I'm not sure I would be able to justify --print KIND=PATH in addition. @bjorn3 do you feel that -o should not apply to --print, or do you feel that both --print + -o and --print KIND=PATH should work?

I can see that for native-static-libs, rustc --emit link=libfoo.a --print native-static-libs=native-static-libs.txt can be potentially more convenient than grabbing notes from a JSON diagnostic.