Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept multiple --error-format flags #62134

Closed
wants to merge 2 commits into from

Conversation

Xanewok
Copy link
Member

@Xanewok Xanewok commented Jun 25, 2019

This makes the compiler accept multiple --error-format flags with the last one taking precedence.
Fixes the error: Option 'error-format' given more than once error when RLS is used together with pipelined build feature enabled in cargo; see #60988 (comment) for more context and rationale.

r? @alexcrichton

Closes rust-lang/rls#1471
Closes rust-lang/rls#1484

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 25, 2019
@alexcrichton alexcrichton added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 26, 2019
@alexcrichton
Copy link
Member

This looks good to me implementation-wise but I don't think I can personally sign off on this becoming insta-stable, could I perhaps request that a @rust-lang/compiler folk proposes stabilization for this via FCP?

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't we also hide this behind an unstable flag that drivers can inject? Something like -Zlenient-flag-duplication-processing or even something that can be passed just by drivers as an argument

Other tools have similar requirements. E.g. clippy and miri use --sysroot, but only if it isn't already set: https://github.com/rust-lang/rust-clippy/blob/e3cb40e4f7e566ffe260b2b9d606485c7c22d642/src/driver.rs#L270

@@ -1816,7 +1816,7 @@ pub fn rustc_optgroups() -> Vec<RustcOptGroup> {
),
opt::opt_s("", "sysroot", "Override the system root", "PATH"),
opt::multi("Z", "", "Set internal debugging options", "FLAG"),
opt::opt_s(
opt::multi_s(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this is abusing the multi argument config. While getopts doesn't support this kind of "pick last" feature, maybe it would make more sense to teach it about it than work around it here by suggesting that giving an argument multiple times makes sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also stop using getopts, it's not that great.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'd either have to

  • duplicate the logic and create a separate multi*_last which only differs by returning optionally a single element (picked last) or
  • introduce some kind of strategy to the multi* but different strategies might have different requirements and return different values (single or multiple)

which I think is more trouble than it's worth in this case?

@Xanewok
Copy link
Member Author

Xanewok commented Jun 26, 2019

Other tools have similar requirements

FWIW RLS also has the same problem with sysroot and we also merge our custom config rustflags by sticking them at the end and deduping the entire thing, which I think is a good another motivating use case.

For some prior art to this kind of change, e.g. GCC accepts last -O value https://stackoverflow.com/questions/5557261/gcc-multiple-optimization-flags, so does ls with --color etc.

@Xanewok
Copy link
Member Author

Xanewok commented Jun 26, 2019

Should I add -Zlenient-flag-duplication-processing? If so, which flags should it affect?

@alexcrichton
Copy link
Member

FWIW I personally consider it sort of a misfeature how lenient gcc/clang are about option parsing. It's definitely convenient and useful some of the time, but more often than not I've found that the leniency leads to bugs or surpsing results as to who's taking precedence (vs who wants to take precedence)

Is it the case that both the RLS and Cargo want JSON output? If that's the case rustc could accept multiple and just assert they're all the same, only producing an error if they're different.

@Dylan-DPC-zz
Copy link

ping from triage @alexcrichton any updates on this? should it mark as blocked, closed or is it waiting for anything?

@alexcrichton
Copy link
Member

This is blocked on figuring out the design for this AFAIK, but I am not going to be able to lead such design.

@JohnCSimon
Copy link
Member

Ping from triage @alexcrichton @rust-lang/compiler this has sat idle for a week and a half.
Can someone else be assigned to this?

@JohnCSimon JohnCSimon added the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label Jul 27, 2019
@JohnTitor
Copy link
Member

Ping from triage: @alexcrichton @rust-lang/compiler can someone figure out and lead the design for this?

@Xanewok
Copy link
Member Author

Xanewok commented Aug 4, 2019

I don’t think it’s required to pursuit this specifically since the underlying error (RLS not working with pipelined cargo) is fixed and I can agree that „last option takes precedence” might not be a silver bullet per Alex’s comment.

I’ll close this for now and come back if I have a better design in mind.

@Xanewok Xanewok closed this Aug 4, 2019
@jyn514
Copy link
Member

jyn514 commented Apr 4, 2020

This also is an issue if I want to control the error format, because cargo also passes --error-format json.

$ cargo rustc --lib -- --error-format short --verbose
   Compiling parser v0.1.0 (/home/joshua/src/rust/rcc/parser)
error: Option 'error-format' given more than once

error: could not compile `parser`.

@jyn514
Copy link
Member

jyn514 commented Apr 4, 2020

Oops, looks like this is --message-format short in Cargo. It's confusing that it's named differently but I guess that's a separate issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Globally enabling cargo pipelining seems to break RLS
9 participants