Rename `ListInit::getValues()` to `getElements()` to better match with
other `ListInit` members like `getElement`. Keep `getValues()` for
existing downstream code but mark it deprecated.
And use it to print the correct default OpenMP version for flang and
flang -fc1.
This change adds an optional `HelpTextsForVariants` to options. This
allows you to change the help text that gets shown in documentation and
`--help` based on the program its being generated for.
As `OptTable` needs to be constexpr compatible, I have used a std::array
of help text variants. Each entry is:
(list of visibilities) - > help text string
So for the OpenMP version we have (flang, fc1) -> "OpenMP version for
flang is...".
So you can have multiple visibilities use the same string. The number of
entries is currently set to 1, and the number of visibilities per entry
is 2, because that's the maximum we need for now. The code is written so
we can increase these numbers later, and the unused elements will be initialised.
I have not applied this to group descriptions just because I don't know
of one that needs changing. It could easily be enabled for those too if
needed. There are minor changes to them just to get it all to compile.
This approach of storing many help strings per option in the 1 driver
library seemed preferable to making a whole new library for Flang (even
if that would mostly be including stuff from Clang).
Currently https://flang.llvm.org/docs/FlangCommandLineReference.html
refers to "Clang" in several of the group descriptions for example:
```
Compilation options
Flags controlling the behavior of Clang during compilation...
```
This is pretty confusing. I'm fixing this by making use of `Program`
from the existing GlobalDocumentation object to substitute in the
program name to these descriptions.
This `Program` has been changed to a proper noun given that it's easier
to lower case a string than capitalise one character (syntax wise). The
tablegen backend has been changed to lower it so that links in the
RST/HTML remain the same as they were before.
To make sure the file is valid when not generating docs, I'm checking a
#define and providing a default GlobalDocumentation if it's not defined.
(I looked for a way to check if a def exists, but tablegen doesn't seem
to have one)
This means that if the DocBrief are used outside of documentation,
they'll say "Clang", which is the same as it always was.
This change does not aim fix option descriptions that refer to clang.
Though we can use parts of this for that, there is only one driver
library so it needs a different approach.
This change also fixes the warning:
```
/home/buildbot/as-worker-4/publish-sphinx-docs/build/tools/flang/docs/Source/FlangCommandLineReference.rst:194: WARNING: unknown document: 'DiagnosticsReference'
```
Which is due to flang docs trying to link to clang docs. Now it will
just tell the reader to go to Clang's page, which is not ideal but it is
easy to find with Google at least.
The current generated ClangCommandLineReference.rst unconditionally
escapes underscores. This leads odd output on the website
https://clang.llvm.org/docs/ClangCommandLineReference.html
For example
-fchar8\_t, -fno-char8\_t
Whether an underscore should be escaped depends on the state. Currently
the escape routine doesn't keep track of the state and currently
underscores are not used in places where they need to be escaped.
Therefore remove the underscore from the list of escaped characters.
This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.
1. We split out some of the flags in ClangFlags to ClangVisibility.
Note that this does not include any subtractive flags.
2. We update the Flag definitions and OptIn/OptOut constructs in
Options.td by hand.
3. We introduce and use a script, update_options_td_flags, to ease
migration of flag definitions in Options.td, and we run that on
Options.td. I intend to remove this later, but I'm committing it so
that downstream forks can use the script to simplify merging.
4. We update calls to OptTable in the clang driver, cc1as, flang, and
clangd to use the visibility APIs instead of Include/Exclude flags.
5. We deprecate the Include/Exclude APIs and add a release note.
*if you are running into conflicts with this change:*
Note that https://reviews.llvm.org/D157150 may also be the culprit and
if so it should be handled first.
The script in `clang/utils/update_options_td_flags.py` can help. Take
the downstream side of all conflicts and then run the following:
```
% cd clang/include/clang/Driver
% ../../../utils/update_options_td_flags.py Options.td > Options.td.new
% mv Options.td.new Options.td
```
This will hopefully be sufficient, please take a look at the diff.
Differential Revision: https://reviews.llvm.org/D157151
Update the `hasFlag` check to account for an Option's groups to better
match how the option parsing logic works, and instead of checking if a
group has include/exclude flags just check if there are any visible
options in it.
This cleans up some the empty sections that are currently emitted in
clang's option docs.
Differential Revision: https://reviews.llvm.org/D157146
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Note:
Some headings in the generated documentation will incorrectly
contain references to Clang, e.g.
"Flags controlling the behaviour of Clang during compilation"
This is because Options.td (Which is shared between both Clang and Flang)
contains hard-coded DocBrief sections. I couldn't find a non-intrusive way
to make this target-dependant, as such I've left this as is, and it will need revisiting later.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
This is a port of f5c666742f7bb4ae79ec79c8acf61dced4d37cc9 to clang's tablegen,
with a better wording.
Differential Revision: https://reviews.llvm.org/D123682
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
r327219 added wrappers to std::sort which randomly shuffle the container before
sorting. This will help in uncovering non-determinism caused due to undefined
sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of
std::sort.
llvm-svn: 328636
We can't see how many arguments are in the meta var name, so just
assume that it is the right number.
Differential Revision: https://reviews.llvm.org/D42840
llvm-svn: 325805
