Can not override previous opt-levels in list of command flags

[mstewartgallus]

If one passes multiple opt-level flags to the compiler (for example -O, and --opt-level=3) then an error results. Instead, the previous setting should be overridden. This is bad because then makefiles don't work easily. For example, I had to use the command line make RUSTFLAGS=--opt-level=3 DISABLE_OPTIMIZE=1 instead of the more obvious make RUSTFLAGS=--opt-level=3 when compiling rust as optimized because of this error.

[catamorphism]

Yeah, this should be fixed. Maybe in addition, there should be a warning message saying something like "you supplied -O and --opt-level=3, but I'm assuming you meant --opt-level=3".

[flaper87]

visiting for triage. This is still valid and should be easy to fix. Setting tags respectively and myself as mentor.

EDIT: The error raised is -O and --opt-level both provided and it is raised by rustc::driver::driver::build_session_options

[thestinger]

I'm not really convinced that this should be changed. A Makefile can set a variable to a default if and only if it's not set manually, and then include it in the command-line.

[flaper87]

@thestinger that's also a good solution. I'm fine with both, TBH. @alexcrichton any opinion on this? Otherwise I think we can close this issue for now.

[huonw]

gcc, ghc, ldmd2 and clang all seem to accept multiple --opt-level/-O params and just take the last one (just the few compilers I had immediately to hand).

[flaper87]

@huonw I find that behavior to be more intuitive but I don't have a strong opinion for this specific case.

[alexcrichton]

I could go either way on this. While not exactly kosher, it is convenient to have overrides like this sometimes.

[kl4ng]

Hey, I'm looking to fix this bug.

Should the default behavior be to accept "--opt-level=X" over "-O" if both are given?
Or should it accept whichever appears last?

if the latter, after looking at the getopts module, it doesn't seem as if there is a way to determine the ordering among two arguments, unless I'm mistaken.

[mstewartgallus]

Whichever is last should be overridden @kl4ng so that appended options can override each other.
It should be possible to have default options that are then overridden as later options are passed in.

[jgallagher]

Should this issue be closed?

[mahkoh]

This bug should be fixed, either by fixing getopts or by moving rustc to another argument parser.

[jgallagher]

Was it not fixed by the closed PR?

[mahkoh]

The PR was closed and not merged.

[huonw]

@jgallagher it was closed, not merged. :)

[jgallagher]

Ahh my mistake, it was closed without merging.

[tamird]

This discussion should probably move to the RFcs repo. cc @steveklabnik

[brson]

Visiting for triage. Specifying -O twice works, specifying -C opt-level twice works. Mixing them does not. I think it should be fixed. This is easy to do. There is explicit code in rustc::session::config that turns this scenario into an error. Instead it should figure out which one appeared last in the argument list and choose it. May require a bit of a hack to make that happen, scanning env::args independently of the getopts processing. Add a test case to src/run-make.

[sanxiyn]

I did this in #32399. The conclusion then was this needs changes to getopts.

[brson]

Removing easy label because lack of agreement on way forward.