allow all command line flags to be passed multiple times, overwriting previous usages

[oli-obk]

For flags that take a single value, rustc should accept the same flag multiple times, with the last flag taking precedence. Currently, when things like --sysroot or --edition are set multiple times, that raises an error: "Option 'foo' given more than once". This is extremely problematic when one tries to build up a command-line argument in a compositional way: there are some default flags, and then some component wants to override some defaults, and then the user has a chance to overwrite even more. It's just impossible to do this right now and e.g. change the default edition to 2021 while still giving later / higher-level components the chance to overwrite that default.

This causes problems like compiler-explorer/compiler-explorer#5429, makes compiler-explorer/compiler-explorer#5349 harder to work around, and is also a pain for Miri where we have to do a lot of rustc command-line patching to get cargo and rustdoc to interpret code rather than execute it. It's a problem for ui_test where we usually want the default edition to not be 2015, but may want to overwrite the edition on a per-test basis -- now ui_test needs to support special //@edition annotations even though //@compile-flags should be more than enough. I'm sure this list could be continued for a while.

As far as I know, it is fairly standard to allow flags to occur multiple times and have e.g. later values of --edition overwrite earlier ones, thus enabling constructs like rustc file.rs --edition 2021 $USER_FLAGS where the user can choose a different edition if they like.

Mentors or Reviewers

• @oli-obk

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler @rust-lang/compiler-contributors

[davidtwco]

@rustbot second

Will need some discussion about clearing/accumulating, as per Zulip discussion, but I think we're interested in this and can work out the details when implementing.

[apiraino]

@rustbot label -final-comment-period +major-change-accepted