Use llvm::is_contained (NFC)

[CommandLine] --help: print "-o <xxx>" instead of "-o=<xxx>"

Accepting -o= is a quirk of CommandLine. For --help, we should print the
conventional "-o <xxx>".

[Support] Use default member initialization (NFC)

Identified with modernize-use-default-member-init.

[config] Remove vestigial LLVM_VERSION_INFO

This has been superseded by the llvm/Support/VCSRevision.h header. So
far as I can tell, nothing in the CMake build sets LLVM_VERSION_INFO. It
was always

[config] Remove vestigial LLVM_VERSION_INFO

This has been superseded by the llvm/Support/VCSRevision.h header. So
far as I can tell, nothing in the CMake build sets LLVM_VERSION_INFO. It
was always undefined, and the ifdefs using it were dead. However, CMake
is very flexible, so it's possible that I missed some ways to set this
variable. One could, for example, probably pass -DLLVM_VERSION_INFO=x on
the command line and get that through to configure_file, or set the
variable in an obscure way (`set(${proj}_VERSION_INFO "x")`). I'm
reasonably confident that isn't happening, but I'd like a second
opinion.

Update the Bazel and gn builds accordingly.

Differential Revision: https://reviews.llvm.org/D126977

show more ...

[Windows] Fix handling of \" in program name on cmd line.

Bugzilla #47579: if you invoke clang on Windows via a pathname in
which a quoted section closes just after a backslash, e.g.

"C:\Program

[Windows] Fix handling of \" in program name on cmd line.

Bugzilla #47579: if you invoke clang on Windows via a pathname in
which a quoted section closes just after a backslash, e.g.

"C:\Program Files\Whatever\"clang.exe

then cmd.exe and CreateProcess will correctly find the binary, because
when they parse the program name at the start of the command line,
they don't regard the \ before the " as having any kind of escaping
effect. This is different from the behaviour of the Windows standard C
library when it parses the rest of the command line, which would
consider that \" not to close the quoted string.

But this confuses windows::GetCommandLineArguments, because the
Windows API function GetCommandLineW() will return a command line
containing that \" sequence, and cl::TokenizeWindowsCommandLine will
tokenize the whole string according to the C library's rules. So it
will misidentify where the program name stops and the arguments start.

To fix this, I've introduced a new variant function
cl::TokenizeWindowsCommandLineFull(), intended to be applied to the
string returned from GetCommandLineW(). It parses the first word of
the command line according to CreateProcess's rules, considering \ to
never be an escaping character; thereafter, it switches over to the C
library rules for the rest of the command line.

Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D122914

show more ...

[Windows] Fix cmd line tokenization of unclosed quotes.

When cl::TokenizeWindowsCommandLine received a command line with an
unterminated double-quoted string at the end, it would discard the
text wi

[Windows] Fix cmd line tokenization of unclosed quotes.

When cl::TokenizeWindowsCommandLine received a command line with an
unterminated double-quoted string at the end, it would discard the
text within that string. That doesn't match the behavior of the
standard Windows C library, which will return the text in the unclosed
quoted string as an argv word.

Fixed, and added extra unit tests in that area.

In some cases (specifically the one in Bugzilla #47579) this could
cause TokenizeWindowsCommandLine to return a zero-length list of
arguments, leading to an array overrun at the call site in
windows::GetCommandLineArguments. Added a check there, for extra
safety: now windows::GetCommandLineArguments will return an error code
instead of failing an assertion.

(This change was written as part of https://reviews.llvm.org/D122914,
but split into a separate commit at the last minute at the code
reviewer's suggestion, because it's fixing an unrelated bug in the
same area. The rest of D122914 will follow in the next commit.)

show more ...

[CommandLine] Remove `may only occur zero or one times!` error

Early adoption of new technologies or adjusting certain code generation/IR optimization thresholds
is often available through some cl::

[CommandLine] Remove `may only occur zero or one times!` error

Early adoption of new technologies or adjusting certain code generation/IR optimization thresholds
is often available through some cl::opt options (which have unstable surfaces).
Specifying such an option twice will lead to an error.

```
% clang -c a.c -mllvm -disable-binop-extract-shuffle -mllvm -disable-binop-extract-shuffle
clang (LLVM option parsing): for the --disable-binop-extract-shuffle option: may only occur zero or one times!
% clang -c a.c -mllvm -hwasan-instrument-reads=0 -mllvm -hwasan-instrument-reads=0
clang (LLVM option parsing): for the --hwasan-instrument-reads option: may only occur zero or one times!
% clang -c a.c -mllvm --scalar-evolution-max-arith-depth=32 -mllvm --scalar-evolution-max-arith-depth=16
clang (LLVM option parsing): for the --scalar-evolution-max-arith-depth option: may only occur zero or one times!
```

The option is specified twice, because there is sometimes a global setting and
a specific file or project may need to override (or duplicately specify) the
value.

The error is contrary to the common practice of getopt/getopt_long command line
utilities that let the last option win and the `getLastArg` behavior used by
Clang driver options. I have seen such errors for several times. I think the
error just makes users inconvenient, while providing very little value on
discouraging production usage of unstable surfaces (this goal is itself
controversial, because developers might not want to commit to a stable surface
too early, or there is just some subtle codegen toggle which is infeasible to
have a driver option). Therefore, I suggest we drop the diagnostic, at least
before the diagnostic gets sufficiently better support for the overridding needs.

Removing the error is a degraded error checking experience. I think this error
checking behavior, if desirable, should be enabled explicitly by tools. Users
preferring the behavior can figure out a way to do so.

Reviewed By: jhenderson, rnk

Differential Revision: https://reviews.llvm.org/D120455

show more ...

[llvm] Use = default (NFC)

Fix edb02d8c5df36bb375df7171b4ba61635564dfb4

[NFC] Use an llvm::DenseMap instead of std::map in CategorizedHelpPrinter::printOptions

It's a recommit of 6427f4c52c31cc36004 (patch included)

Revert "[NFC] Use an llvm::DenseMap instead of std::map in CategorizedHelpPrinter::printOptions"

This reverts commit 6427f4c52c31cc36004b14825e6598cd4a43f385.
Breaks a bunch of tests, see e.g. http:

Revert "[NFC] Use an llvm::DenseMap instead of std::map in CategorizedHelpPrinter::printOptions"

This reverts commit 6427f4c52c31cc36004b14825e6598cd4a43f385.
Breaks a bunch of tests, see e.g. http://45.33.8.238/linux/66340/step_7.txt
or https://lab.llvm.org/buildbot/#/builders/139/builds/16807

show more ...

Revert "Fix build issue in assert mode introduced by 6427f4c52c31cc36004"

This reverts commit d65a3b3265d058ce1f0ac82fa4d0826bf1b2bbaf.
Breaks build everywhere, see e.g. http://45.33.8.238/linux/663

Revert "Fix build issue in assert mode introduced by 6427f4c52c31cc36004"

This reverts commit d65a3b3265d058ce1f0ac82fa4d0826bf1b2bbaf.
Breaks build everywhere, see e.g. http://45.33.8.238/linux/66344/step_4.txt
or https://lab.llvm.org/buildbot/#/builders/139/builds/16811

show more ...

Fix build issue in assert mode introduced by 6427f4c52c31cc36004

After 6427f4c52c31cc36004, one should use SortedCategories to check category
validity.

[NFC] Use an llvm::DenseMap instead of std::map in CategorizedHelpPrinter::printOptions

Move STLFunctionalExtras out of STLExtras

Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport

Perhaps more interestingly,

Move STLFunctionalExtras out of STLExtras

Only using that change in StringRef already decreases the number of
preoprocessed lines from 7837621 to 7776151 for LLVMSupport

Perhaps more interestingly, it shows that many files were relying on the
inclusion of StringRef.h to have the declaration from STLExtras.h. This
patch tries hard to patch relevant part of llvm-project impacted by this
hidden dependency removal.

Potential impact:
- "llvm/ADT/StringRef.h" no longer includes <memory>,
"llvm/ADT/Optional.h" nor "llvm/ADT/STLExtras.h"

Related Discourse thread:
https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831

show more ...

[Support] Expand `<CFGDIR>` as the base directory in configuration files.

Extends response file expansion to recognize `<CFGDIR>` and expand to the
current file's directory. This makes it much easie

[Support] Expand `<CFGDIR>` as the base directory in configuration files.

Extends response file expansion to recognize `<CFGDIR>` and expand to the
current file's directory. This makes it much easier to author clang config
files rooted in portable, potentially not-installed SDK directories.

A typical use case may be something like the following:

```
# sample_sdk.cfg
--target=sample
-isystem <CFGDIR>/include
-L <CFGDIR>/lib
-T <CFGDIR>/ldscripts/link.ld
```

Reviewed By: sepavloff

Differential Revision: https://reviews.llvm.org/D115604

show more ...

[Support] Use range-based for loops (NFC)

fix inverted logic for HideUnrelatedOptions

It seems clearer to me that this would check for *any of* instead of
*all of* these option categories, as it looks to me like that was the
intent. But app

fix inverted logic for HideUnrelatedOptions

It seems clearer to me that this would check for *any of* instead of
*all of* these option categories, as it looks to me like that was the
intent. But apparently this logic has always has been inverted, and
possibly never fully used?

Differential Revision: https://reviews.llvm.org/D114572

show more ...

Reset all options in cl::ResetCommandLineParser()

Reset cl::Positional, cl::Sink and cl::ConsumeAfter options as well in cl::ResetCommandLineParser().

Reviewed By: rriddle, sammccall

Differential

Reset all options in cl::ResetCommandLineParser()

Reset cl::Positional, cl::Sink and cl::ConsumeAfter options as well in cl::ResetCommandLineParser().

Reviewed By: rriddle, sammccall

Differential Revision: https://reviews.llvm.org/D103356

show more ...

[Support] Initialize common options in `getRegisteredOptions`

This allows users accessing options in libSupport before invoking
`cl::ParseCommandLineOptions`, and also matches the behavior before
D1

[Support] Initialize common options in `getRegisteredOptions`

This allows users accessing options in libSupport before invoking
`cl::ParseCommandLineOptions`, and also matches the behavior before
D105959.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D106334

show more ...

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSuppor

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.

Reviewed By: lattner, jpienaar

Differential Revision: https://reviews.llvm.org/D105959

show more ...

Revert "Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer"

This reverts commit af9321739b20becf170e6bb5060b8d780e1dc8dd.
Still some specific co

Revert "Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer"

This reverts commit af9321739b20becf170e6bb5060b8d780e1dc8dd.
Still some specific config broken in some way that requires more
investigation.

show more ...

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSuppor

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.

Reviewed By: lattner, jpienaar

Differential Revision: https://reviews.llvm.org/D105959

show more ...

Revert "Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer"

This reverts commit 42f588f39c5ce6f521e3709b8871d1fdd076292f.
Broke some buildbots

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSuppor

Use ManagedStatic and lazy initialization of cl::opt in libSupport to make it free of global initializer

We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.

Reviewed By: lattner, jpienaar

Differential Revision: https://reviews.llvm.org/D105959

show more ...