[PATCH] D122654: [doc] Improve clang auto-generated help

Mon May 9 06:41:28 PDT 2022

awarzynski added a subscriber: ekieri.
awarzynski added a comment.

In D122654#3454126 <https://reviews.llvm.org/D122654#3454126>, @serge-sans-paille wrote:

> Thanks for jumping in!

Np! And apologies for going radio silent for so long, completely lost track of time!

> This looks like a design error to me. The `Values` field is already used for code completion, so the behavior is already flawed...

Hm, why wouldn't you want to auto-complete with possible values too? For example, `-std=c<tab>` will only work if possible values are also used in auto-completion.

> Whould it make sense to have a common file for shared options, and then a clang-specific and a flang specifc option for options with different values / meaning etc ?

Yes! :) Many options do/will have identical meaning in both frontends. But I agree that there should be a dedicated file for every driver:

- `clang` (Clang's compiler driver)
- `clang -cc1` (Clang's frontend driver)
- `clang -cc1as` (Clang's integrated assembler driver)
- `flang` (Flang's compiler driver)
- `flang-new -fc1` (Flang's frontend driver)
- <anything that I've missed>

Perhaps this is more extreme than what you had in mind? Shared options (with semantics that don't differ between drivers) could be kept in some common *.td file.

In general, IMHO Options.td <https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Driver/Options.td> is  a good example of code re-use not being such a good thing :) @ekieri made some nice improvements there recently: https://reviews.llvm.org/D123070. And I discussed this briefly in the past: https://lists.llvm.org/pipermail/cfe-dev/2020-July/066393.html  too.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122654/new/

https://reviews.llvm.org/D122654