cargo rustc should detect when one of the arguments passed is either --out-dir or -o and not pass its own

[m4b]

If you do:

cargo rustc --verbose -- -o derp
   Compiling test v0.1.0 (file:///home/m4b/tmp/test)
     Running `rustc src/main.rs --crate-name test --crate-type bin -g -o derp --out-dir /home/m4b/tmp/test/target/debug --emit=dep-info,link -L dependency=/home/m4b/tmp/test/target/debug -L dependency=/home/m4b/tmp/test/target/debug/deps`
warning: ignoring specified output filename because multiple outputs were requested
warning: ignoring --out-dir flag due to -o flag.

we're told that:

1. the -o flag is ignored because multiple outputs are given (I assume this is due to --out-dir)
2. then the --out-dir flag is ignored because -o is given

and the derp binary is produced anyway (in the PWD)... looks to me like the command line logic is a little wonky.

I would expect to to not receive warnings.

Similarly, if you provide --out-dir, cargo will completely refuse to compile the program:

cargo rustc --verbose -- --out-dir=.
   Compiling test v0.1.0 (file:///home/m4b/tmp/test)
     Running `rustc src/main.rs --crate-name test --crate-type bin -g --out-dir=. --out-dir /home/m4b/tmp/test/target/debug --emit=dep-info,link -L dependency=/home/m4b/tmp/test/target/debug -L dependency=/home/m4b/tmp/test/target/debug/deps`
error: Option 'out-dir' given more than once.
error: Could not compile `test`.

Caused by:
  Process didn't exit successfully: `rustc src/main.rs --crate-name test --crate-type bin -g --out-dir=. --out-dir /home/m4b/tmp/test/target/debug --emit=dep-info,link -L dependency=/home/m4b/tmp/test/target/debug -L dependency=/home/m4b/tmp/test/target/debug/deps` (exit code: 101)

I would expect:

1. cargo to use my --out-dir when I pass it, instead of the default value
2. not refuse to compile my program

I think some of the issues here are some flags passed into rustc via cargo are privileged and others are not. I just don't know which (and probably none should be).

Lastly, I've noticed that passing a custom --emit is actually duplicated, and again, does not replace the default.

cargo rustc --verbose -- --emit obj
   Compiling test v0.1.0 (file:///home/m4b/tmp/test)
     Running `rustc src/main.rs --crate-name test --crate-type bin -g --emit obj --out-dir /home/m4b/tmp/test/target/debug --emit=dep-info,link -L dependency=/home/m4b/tmp/test/target/debug -L dependency=/home/m4b/tmp/test/target/debug/deps`

Note there are two --emit flags. In the case of emitting an object file, it doesn't make sense to (also) produce the final binary/static lib, which is the behavior I'm seeing.

[alexcrichton]

Some of this is related to the compiler's handling of options (e.g. ignoring --out-dir when -o is specified), but Cargo should probably detect when one of the arguments passed is either --out-dir or -o and not pass its own.

[m4b]

Yea, agreed. Right now I'm hacking the missing out-dir by relying on -o outputting to the top directory. Specifying an out-dir wouldn't be as necessary if there was a subcommand to output the cargo build dir though, at least for my use case

[froydnj]

I think this issue is also responsible for --emit dep-info not putting the dependency info in the right place, which is problematic for integrating cargo into third-party build systems.

[alexcrichton]

@froydnj this probably isn't what you'd want for that anyway as it doesn't include any dependency information. In general the integration of Cargo into third-party build systems will likely be much more first-class than this in the long run.

[froydnj]

@alexcrichton But wouldn't you handle the fix for this bug similarly to how you would handle --emit? e.g. when invoking something like:

cargo rustc --verbose [..options..] -- --emit dep-info=$PATH,link=librul.a

the dep-info isn't actually placed at $PATH, but instead at librul.d in the current directory. cargo's output in this case is:

rustc rul.rs --crate-name rul [...] --emit dep-info=.deps/librul.a.pp,link=librul.a [...] --emit=dep-info,link [...]

[alexcrichton]

@froydnj yeah I suspect fixing this would lead to a fix to --emit dep-info as well, it'd just emit the dep info for one crate, not the entire dependency graph

[epage]

This would require us to parse and interpret rustc arguments which is a complicated endeavor that I do not think we should take on.

I think we should view setting of rustflags to be a more advanced use case with caveat emptor and that we should instead be finding why people use them and find more official ways of satisfying their workflows (#12739).

As such, I'm proposing to the cargo team that we close this.

[weihanglo]

It's great to have #12739 for consolidating discussions of RUSTFLAGS user experience in one place.

Thanks for the triage. Also thanks the original reporter for reporting this!

Closing.