[PATCH] D94169: [clang][driver] Restore the original help text for `-I`

Andrzej Warzynski via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 8 08:52:45 PST 2021


awarzynski added a comment.

Thank you all for your input. Let me summarize.

**SUGGESTION 1**
Tweak the wording to clarify that it is Clang-specific. That's a good compromise IMO. It highlights that the described semantics apply to Clang only. And I'm not aware of any other way to achieve this right now (i.e. without intrusive refactoring).

**SUGGESTION 2:**
The description of `-I` in `-help` and `ClangCommandLineReference.rst` are made independent of each other (so that `-help` can be tweaked to suit both Clang and Flang).

`ClangCommandLineReference.rst` is basically generated from `Options.td`, so any modification to Options.td will affect the user-facing docs.

>From docs/CMakeLists.txt:

  gen_rst_file_from_td(ClangCommandLineReference.rst -gen-opt-docs ../include/clang/Driver/ClangOptionDocs.td docs-clang-html)

>From ClangOptionDocs.td:

  include "Options.td"

I don't see any straightforward solution here that would allow different descriptions for `-I` in `-help` and in the user-facing docs. Not without completely refactoring how ClangCommandLineReference.rst is produced.

**SUGGESTION 3**
Ideally, we'd have one help message for `-I` for Clang and another one for Flang (in `Options.td`). Unfortunately, AFAIK, there is no easy way to tweak the output of `-help`. The current API is quite inflexible in this respect. This was brought-up at some point last year [1][2]. From the limited feedback I'm guessing that that would also require a major refactor.

**SUGGESTION 4**
We add a new definition for `-I` for Flang, e.g. `def I_for_flang`.

This solves the problem, but adds yet another option definition. Note that `libclangDriver` creates only one global list of all options:

- https://github.com/llvm/llvm-project/blob/80dee7965dffdfb866afa9d74f3a4a97453708b2/clang/lib/Driver/DriverOptions.cpp#L42-L55
- https://github.com/llvm/llvm-project/blob/80dee7965dffdfb866afa9d74f3a4a97453708b2/clang/include/clang/Driver/Options.h#L43-L52

This means that both Flang and Clang will have access to `OPT_I` and `OPT_I_for_flang` (C++ options generated from Options.td). These can be hidden from the user, but will still be available. Also, this would mean the massive table of `libclangDriver` options keeps growing.

Is that how we should proceed moving forward when option names are identical for Clang and Flang, but the semantics are slightly different?

[1] https://lists.llvm.org/pipermail/llvm-dev/2020-July/143745.html
[2] https://lists.llvm.org/pipermail/cfe-dev/2020-October/066953.html

**Few final points**
I would really appreciate a compromise that does not require any major refactoring in Clang at this stage. 
We are ready to add `-I`to Flang and we have a bunch of patches almost ready that depend on it. 
I appreciate that this is just one option, but we are likely to experience more inconsistencies like this in the near future.

Also, for reference, output from  `gcc` and `gfortran`:

  -I <dir>                    Add <dir> to the end of the main include path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94169



More information about the cfe-commits mailing list