History log of /llvm-project/llvm/lib/Support/CommandLine.cpp (Results 101 – 125 of 443)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 0303e8a3 11-May-2019 Don Hinton <hintonda@gmail.com>

[CommandLine] Add long option flag for cl::ParseCommandLineOptions . Part 5 of 5

Summary:
If passed, the long option flag makes the CommandLine parser
mimic the behavior or GNU getopt_long. Short o

[CommandLine] Add long option flag for cl::ParseCommandLineOptions . Part 5 of 5

Summary:
If passed, the long option flag makes the CommandLine parser
mimic the behavior or GNU getopt_long. Short options are a single
character prefixed by a single dash, and long options are multiple
characters prefixed by a double dash.

This patch was motivated by the discussion in the following thread:
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131786.html

Reviewed By: MaskRay

Tags: #llvm

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

llvm-svn: 360532

show more ...


# 102ec097 07-May-2019 Don Hinton <hintonda@gmail.com>

[CommandLine] Allow Options to specify multiple OptionCategory's.

Summary:
It's not uncommon for separate components to share common
Options, e.g., it's common for related Passes to share Options in

[CommandLine] Allow Options to specify multiple OptionCategory's.

Summary:
It's not uncommon for separate components to share common
Options, e.g., it's common for related Passes to share Options in
addition to the Pass specific ones.

With this change, components can use OptionCategory's to simply help
output even if some of the options are shared.

Reviewed By: MaskRay

Tags: #llvm

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

llvm-svn: 360179

show more ...


# f6eac2dd 03-May-2019 Don Hinton <hintonda@gmail.com>

[CommandLine] Enable Grouping for short options by default. Part 4 of 5

Summary:
This change enables `cl::Grouping` for short options --
options with names of a single character. This is consisten

[CommandLine] Enable Grouping for short options by default. Part 4 of 5

Summary:
This change enables `cl::Grouping` for short options --
options with names of a single character. This is consistent with GNU
getopt behavior.

Reviewers: rnk, MaskRay

Reviewed By: MaskRay

Subscribers: thopre, cfe-commits, MaskRay, rupprecht, hiraditya, llvm-commits

Tags: #llvm, #clang

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

llvm-svn: 359917

show more ...


# c242be40 03-May-2019 Don Hinton <hintonda@gmail.com>

[CommandLine] Change help output to prefix long options with `--` instead of `-`. NFC . Part 3 of 5

Summary:
By default, `parseCommandLineOptions()` will accept either a
`-` or `--` prefix for long

[CommandLine] Change help output to prefix long options with `--` instead of `-`. NFC . Part 3 of 5

Summary:
By default, `parseCommandLineOptions()` will accept either a
`-` or `--` prefix for long options -- options with names longer than
a single character.

While this change does not affect behavior, it will be helpful with a
subsequent change that requires long options use the `--` prefix.

Reviewers: rnk, thopre

Reviewed By: thopre

Subscribers: thopre, cfe-commits, hiraditya, llvm-commits

Tags: #llvm, #clang

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

llvm-svn: 359909

show more ...


# 89e583b8 29-Apr-2019 Don Hinton <hintonda@gmail.com>

[CommandLine] Don't allow unlimitted dashes for options. Part 1 or 5

Summary:
Prior to this patch, the CommandLine parser would strip an
unlimitted number of dashes from options. This patch limits

[CommandLine] Don't allow unlimitted dashes for options. Part 1 or 5

Summary:
Prior to this patch, the CommandLine parser would strip an
unlimitted number of dashes from options. This patch limits it to
two.

Reviewers: rnk

Reviewed By: rnk

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 359480

show more ...


# c06a470f 24-Apr-2019 Reid Kleckner <rnk@google.com>

Try once more to ensure constant initializaton of ManagedStatics

First, use the old style of linker initialization for MSVC 2019 in
addition to 2017. MSVC 2019 emits a dynamic initializer for
Manage

Try once more to ensure constant initializaton of ManagedStatics

First, use the old style of linker initialization for MSVC 2019 in
addition to 2017. MSVC 2019 emits a dynamic initializer for
ManagedStatic when compiled in debug mode, and according to zturner,
also sometimes in release mode. I wasn't able to reproduce that, but it
seems best to stick with the old code that works.

When clang is using the MSVC STL, we have to give ManagedStatic a
constexpr constructor that fully zero initializes all fields, otherwise
it emits a dynamic initializer. The MSVC STL implementation of
std::atomic has a non-trivial (but constexpr) default constructor that
zero initializes the atomic value. Because one of the fields has a
non-trivial constructor, ManagedStatic ends up with a non-trivial ctor.
The ctor is not constexpr, so clang ends up emitting a dynamic
initializer, even though it simply does zero initialization. To make it
constexpr, we must initialize all fields of the ManagedStatic.

However, while the constructor that takes a pointer is marked constexpr,
clang says it does not evaluate to a constant because it contains a cast
from a pointer to an integer. I filed this as:
https://developercommunity.visualstudio.com/content/problem/545566/stdatomic-value-constructor-is-not-actually-conste.html

Once we do that, we can add back the
LLVM_REQUIRE_CONSTANT_INITIALIZATION marker, and so far as I'm aware it
compiles successfully on all supported targets.

llvm-svn: 359135

show more ...


# b5f39845 24-Apr-2019 Fangrui Song <maskray@google.com>

[CommandLine] Provide parser<unsigned long> instantiation to allow cl::opt<uint64_t> on LP64 platforms

Summary:
And migrate opt<unsigned long long> to opt<uint64_t>

Fixes PR19665

Differential Revi

[CommandLine] Provide parser<unsigned long> instantiation to allow cl::opt<uint64_t> on LP64 platforms

Summary:
And migrate opt<unsigned long long> to opt<uint64_t>

Fixes PR19665

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

llvm-svn: 359068

show more ...


# 1826095a 16-Apr-2019 Shoaib Meenai <smeenai@fb.com>

Reapply [Support] Fix recursive response file expansion guard

The test in the dependent revision has been fixed for Windows.

Original commit message:

Response file expansion limits the amount of e

Reapply [Support] Fix recursive response file expansion guard

The test in the dependent revision has been fixed for Windows.

Original commit message:

Response file expansion limits the amount of expansion to prevent
potential infinite recursion. However, the current logic assumes that
any argument beginning with @ is a response file, which is not true for
e.g. `-Xlinker -rpath -Xlinker @executable_path/../lib` on Darwin.
Having too many of these non-response file arguments beginning with @
prevents actual response files from being expanded. Instead, limit based
on the number of successful response file expansions, which should still
prevent infinite recursion but also avoid false positives.

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

> llvm-svn: 358452

llvm-svn: 358466

show more ...


# d60ac111 15-Apr-2019 Shoaib Meenai <smeenai@fb.com>

Revert [Support] Fix recursive response file expansion guard

This reverts r358452 (git commit c8df4fb9c3865eac52a99602c26bbc070098c3d4)

A dependent commit breaks the Windows buildbots.

llvm-svn: 3

Revert [Support] Fix recursive response file expansion guard

This reverts r358452 (git commit c8df4fb9c3865eac52a99602c26bbc070098c3d4)

A dependent commit breaks the Windows buildbots.

llvm-svn: 358460

show more ...


# c8df4fb9 15-Apr-2019 Shoaib Meenai <smeenai@fb.com>

[Support] Fix recursive response file expansion guard

Response file expansion limits the amount of expansion to prevent
potential infinite recursion. However, the current logic assumes that
any argu

[Support] Fix recursive response file expansion guard

Response file expansion limits the amount of expansion to prevent
potential infinite recursion. However, the current logic assumes that
any argument beginning with @ is a response file, which is not true for
e.g. `-Xlinker -rpath -Xlinker @executable_path/../lib` on Darwin.
Having too many of these non-response file arguments beginning with @
prevents actual response files from being expanded. Instead, limit based
on the number of successful response file expansions, which should still
prevent infinite recursion but also avoid false positives.

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

llvm-svn: 358452

show more ...


# b85f74a2 15-Apr-2019 Don Hinton <hintonda@gmail.com>

[CommandLineParser] Add DefaultOption flag

Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as ne

[CommandLineParser] Add DefaultOption flag

Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.

Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.

(relanding after revert, r358414)
Added DefaultOptions.clear() to reset().

Reviewers: alexfh, klimek

Reviewed By: klimek

Subscribers: kristina, MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits

Tags: #clang, #llvm

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

llvm-svn: 358428

show more ...


# 70921d4a 15-Apr-2019 Ilya Biryukov <ibiryukov@google.com>

Revert r358337: "[CommandLineParser] Add DefaultOption flag"

The change causes test failures under asan. Reverting to unbreak our
integrate.

llvm-svn: 358414


# 7d2021de 13-Apr-2019 Don Hinton <hintonda@gmail.com>

[CommandLineParser] Add DefaultOption flag

Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as ne

[CommandLineParser] Add DefaultOption flag

Summary: Add DefaultOption flag to CommandLineParser which provides a
default option or alias, but allows users to override it for some
other purpose as needed.

Also, add `-h` as a default alias to `-help`, which can be seamlessly
overridden by applications like llvm-objdump and llvm-readobj which
use `-h` as an alias for other options.

Reviewers: alexfh, klimek

Reviewed By: klimek

Subscribers: MaskRay, mehdi_amini, inglorion, dexonsmith, hiraditya, llvm-commits, jhenderson, arphaman, cfe-commits

Tags: #clang, #llvm

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

llvm-svn: 358337

show more ...


# 4312fee0 04-Apr-2019 Reid Kleckner <rnk@google.com>

Appease STLs where std::atomic<void*> lacks a constexpr default ctor

MSVC 2019 casts the pointer to a pointer-sized integer, which is a
reinterpret_cast, which is invalid in a constexpr context, so

Appease STLs where std::atomic<void*> lacks a constexpr default ctor

MSVC 2019 casts the pointer to a pointer-sized integer, which is a
reinterpret_cast, which is invalid in a constexpr context, so I have to
remove the LLVM_REQUIRES_CONSTANT_INITIALIZATION annotation for now.

llvm-svn: 357716

show more ...


# 41fe3a54 04-Apr-2019 Reid Kleckner <rnk@google.com>

Ensure that ManagedStatic is constant initialized in MSVC 2017 & 2019

Fixes PR41367.

This effectively relands r357655 with a workaround for MSVC 2017.

I tried various approaches with unions, but I

Ensure that ManagedStatic is constant initialized in MSVC 2017 & 2019

Fixes PR41367.

This effectively relands r357655 with a workaround for MSVC 2017.

I tried various approaches with unions, but I ended up going with this
ifdef approach because it lets us write the proper C++11 code that we
want to write, with a separate workaround that we can delete when we
drop MSVC 2017 support.

This also adds LLVM_REQUIRE_CONSTANT_INITIALIZATION, which wraps
[[clang::require_constant_initialization]]. This actually detected a
minor issue when using clang-cl where clang wasn't able to use the
constexpr constructor in MSVC's STL, so I switched back to using the
default ctor of std::atomic<void*>.

llvm-svn: 357714

show more ...


Revision tags: llvmorg-8.0.0
# 6823c823 14-Mar-2019 Sunil Srivastava <sunil_srivastava@playstation.sony.com>

Handle consecutive-double-quotes in Windows argument parsing

Windows command line argument processing treats consecutive double quotes
as a single double-quote. This patch implements this functional

Handle consecutive-double-quotes in Windows argument parsing

Windows command line argument processing treats consecutive double quotes
as a single double-quote. This patch implements this functionality.

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

llvm-svn: 356193

show more ...


Revision tags: llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4
# a38432ce 01-Mar-2019 Igor Kudrin <ikudrin@accesssoftek.com>

[CommandLine] Allow grouping options which can have values.

This patch allows all forms of values for options to be used at the end
of a group. With the fix, it is possible to follow the way GNU bin

[CommandLine] Allow grouping options which can have values.

This patch allows all forms of values for options to be used at the end
of a group. With the fix, it is possible to follow the way GNU binutils
tools handle grouping options better. For example, the -j option can be
used with objdump in any of the following ways:

$ objdump -d -j .text a.o
$ objdump -d -j.text a.o
$ objdump -dj .text a.o
$ objdump -dj.text a.o

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

llvm-svn: 355185

show more ...


# 875f0582 01-Mar-2019 Igor Kudrin <ikudrin@accesssoftek.com>

[CommandLine] Do not crash if an option has both ValueRequired and Grouping.

If an option, which requires a value, has a `cl::Grouping` formatting
modifier, it works well as far as it is used at the

[CommandLine] Do not crash if an option has both ValueRequired and Grouping.

If an option, which requires a value, has a `cl::Grouping` formatting
modifier, it works well as far as it is used at the end of a group,
or as a separate argument. However, if the option appears accidentally
in the middle of a group, the program just crashes. This patch prints
an error message instead.

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

llvm-svn: 355184

show more ...


Revision tags: llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2
# f929a0f8 05-Feb-2019 Thomas Preud'homme <thomasp@graphcore.ai>

Recommit: Add support for prefix-only CLI options

Summary:
Add support for options that always prefix their value, giving an error
if the value is in the next argument or if the option is given a va

Recommit: Add support for prefix-only CLI options

Summary:
Add support for options that always prefix their value, giving an error
if the value is in the next argument or if the option is given a value
assignment (ie. opt=val). This is the desired behavior for the -D option
of FileCheck for instance.

Copyright:
- Linaro (changes in version 2 of revision D55940)
- GraphCore (changes in later versions and introduced when creating
D56549)

Reviewers: jdenny

Subscribers: llvm-commits, probinson, kristina, hiraditya,
JonChesterfield

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

llvm-svn: 353172

show more ...


# 9652652a 04-Feb-2019 James Henderson <jh7370@my.bristol.ac.uk>

[CommandLine] Don't print empty sentinel values from EnumValN lists in help text

In order to make an option value truly optional, both the ValueOptional
attribute and an empty-named value are requir

[CommandLine] Don't print empty sentinel values from EnumValN lists in help text

In order to make an option value truly optional, both the ValueOptional
attribute and an empty-named value are required. Prior to this change,
this empty-named value appears in the command-line help text:

-some-option - some help text
=v1 - description 1
=v2 - description 2
= -

This change improves the help text for these sort of options in a number
of ways:

1) ValueOptional options with an empty-named value now print their help
text twice: both without and then with '=<value>' after the name. The
latter version then lists the allowed values after it.
2) Empty-named values with no help text in ValueOptional options are not
listed in the permitted values.

-some-option - some help text
-some-option=<value> - some help text
=v1 - description 1
=v2 - description 2

3) Otherwise empty-named options are printed as =<empty> rather than
simply '='.
4) Option values without help text do not have the '-' separator
printed.

-some-option=<value> - some help text
=v1 - description 1
=v2
=<empty> - description

It also tweaks the llvm-symbolizer -functions help text to not print a
trailing ':' as that looks bad combined with 1) above.

This is mostly a reland of r353048 which in turn was a reland of
r352750.

Reviewed by: ruiu, thopre, mstorsjo

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

llvm-svn: 353053

show more ...


# c9e6861a 04-Feb-2019 James Henderson <jh7370@my.bristol.ac.uk>

Revert r353048.

It was causing unexpected unit test failures on build bots.

llvm-svn: 353050


# d90b5a2e 04-Feb-2019 James Henderson <jh7370@my.bristol.ac.uk>

[CommandLine] Don't print empty sentinel values from EnumValN lists in help text

In order to make an option value truly optional, both the ValueOptional
attribute and an empty-named value are requir

[CommandLine] Don't print empty sentinel values from EnumValN lists in help text

In order to make an option value truly optional, both the ValueOptional
attribute and an empty-named value are required. Prior to this change,
this empty-named value appears in the command-line help text:

-some-option - some help text
=v1 - description 1
=v2 - description 2
= -

This change improves the help text for these sort of options in a number
of ways:

1) ValueOptional options with an empty-named value now print their help
text twice: both without and then with '=<value>' after the name. The
latter version then lists the allowed values after it.
2) Empty-named values with no help text in ValueOptional options are not
listed in the permitted values.

-some-option - some help text
-some-option=<value> - some help text
=v1 - description 1
=v2 - description 2

3) Otherwise empty-named options are printed as =<empty> rather than
simply '='.
4) Option values without help text do not have the '-' separator
printed.

-some-option=<value> - some help text
=v1 - description 1
=v2
=<empty> - description

It also tweaks the llvm-symbolizer -functions help text to not print a
trailing ':' as that looks bad combined with 1) above.

This is mostly a reland of r352750.

Reviewed by: ruiu, thopre, mstorsjo

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

llvm-svn: 353048

show more ...


# 212833ce 01-Feb-2019 James Henderson <jh7370@my.bristol.ac.uk>

Revert r352750.

This was causing a build bot failure:
http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/15346/

llvm-svn: 352848


# 140f75f6 31-Jan-2019 James Henderson <jh7370@my.bristol.ac.uk>

[CommandLine] Improve help text for cl::values style options

In order to make an option value truly optional, both the ValueOptional
and an empty-named value are required. This empty-named value app

[CommandLine] Improve help text for cl::values style options

In order to make an option value truly optional, both the ValueOptional
and an empty-named value are required. This empty-named value appears in
the command-line help text, which is not ideal.

This change improves the help text for these sort of options in a number
of ways:
1) ValueOptional options with an empty-named value now print their help
text twice: both without and then with '=<value>' after the name. The
latter version then lists the allowed values after it.
2) Empty-named values with no help text in ValueOptional options are not
listed in the permitted values.
3) Otherwise empty-named options are printed as =<empty> rather than
simply '='.
4) Option values without help text do not have the '-' separator
printed.

It also tweaks the llvm-symbolizer -functions help text to not print a
trailing ':' as that looks bad combined with 1) above.

Reviewed by: thopre, ruiu

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

llvm-svn: 352750

show more ...


# 5cb11930 27-Jan-2019 Thomas Preud'homme <thomasp@graphcore.ai>

Revert "Add support for prefix-only CLI options"

This reverts commit r351038.

llvm-svn: 352310


12345678910>>...18