If no MetaVar is provided and an enumeration of values is set, document it in
the same way Python argparse does. Also add a proper unittest for help strings
This is a follow-up to 6d7317894f89cea29a2ecf7d86ac88adc40a5eaa
Differential D122654
[doc] Improve clang auto-generated help serge-sans-paille on Mar 29 2022, 6:35 AM. Authored by
Details
If no MetaVar is provided and an enumeration of values is set, document it in This is a follow-up to 6d7317894f89cea29a2ecf7d86ac88adc40a5eaa
Diff Detail
Event TimelineComment Actions Generally looks reasonable to me, but it looks like Precommit CI caught some valid failures that need to be fixed: Failed Tests (2): Flang :: Driver/driver-help-hidden.f90 Flang :: Driver/driver-help.f90
Comment Actions Hi @serge-sans-paille, I just saw your comment on Discourse. Looking specifically at: ! HELP-FC1-NEXT: -std={c89,c90,iso9899:1990,iso9899:199409,gnu89,gnu90,c99,iso9899:1999,c9x,iso9899:199x,gnu99,gnu9x,c11,iso9899:2011,c1x,iso9899:201x,gnu11,gnu1x,c17,iso9899:2017,c18,iso9899:2018,gnu17,gnu18,c2x,gnu2x,c++98,c++03,gnu++98,gnu++03,c++11,c++0x,gnu++11,gnu++0x,c++14,c++1y,gnu++14,gnu++1y,c++17,c++1z,gnu++17,gnu++1z,c++20,c++2a,gnu++20,gnu++2a,c++2b,gnu++2b,cl1.0,cl,cl1.1,cl1.2,cl2.0,cl3.0,clc++1.0,clc++,clc++2021,CL,CL1.1,CL1.2,CL2.0,CL3.0,CLC++,CLC++1.0,CLC++2021,cuda,hip,hlsl,hlsl2015,hlsl2016,hlsl2017,hlsl2018,hlsl2021,hlsl202x,} I think that listing the available options for -std= is helpful, but I'm not sure whether clang -help is the right place. It's already quite cluttered and impossible to navigate without piping to e.g. grep. In the past, we tried using DocBrief in Options.td for longer option comments. That wouldn't change the contents of clang -help, but IIRC, would be included in https://clang.llvm.org/docs/ClangCommandLineReference.html. In general, I think that it would be great to re-factor and organise clang -help a bit, but that would be a bigger job. On a different note, we should definitely avoiding making flang-new display various C or C++ standards as available options for -std=<val>. Basically, -std=c++98 (and other similar options) are not supported by flang-new and should not be printed in flang-new -help. HTH, Comment Actions Thanks for jumping in! This looks like a design error to me. The Values field is already used for code completion, so the behavior is already flawed... 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 ? Comment Actions Np! And apologies for going radio silent for so long, completely lost track of time!
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.
Yes! :) Many options do/will have identical meaning in both frontends. But I agree that there should be a dedicated file for every driver:
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 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. |
Use a Twine?