Summary:
The primary goal of this patch is to remove the need for MarkOptionsChanged(). That goal is accomplished by having addOption and removeOption properly sort the options.
This patch puts the new add and remove functionality on a CommandLineParser class that is a placeholder. Some of the functionality in this class will need to be merged into the OptionRegistry, and other bits can hopefully be in a better abstraction.
This patch also removes the RegisteredOptionList global, and the need for cl::Option objects to be linked list nodes.
The changes in CommandLineTest.cpp are required because these changes shift when we validate that options are not duplicated. Before this change duplicate options were only found during certain cl API calls (like cl::ParseCommandLine). With this change duplicate options are found during option construction.
Reviewers: dexonsmith, chandlerc, pete
Reviewed By: pete
Subscribers: pete, majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D7132
llvm-svn: 227345
r227148 added test CommandLineTest.HideUnrelatedOptionsMulti which repeatedly
outputs two following lines:
-tool: CommandLine Error: Option 'test-option-1' registered more than once!
-tool: CommandLine Error: Option 'test-option-2' registered more than once!
r227154 depends on changes from r227148
llvm-svn: 227167
Need a new API for clang-modernize that allows specifying a list of option categories to remain visible. This will allow clang-modernize to move off getRegisteredOptions.
llvm-svn: 227140
Summary:
This puts all the options that CommandLine.cpp implements into a category so that the APIs to hide options can not hide based on the generic category instead of string matching a partial list of argument strings.
This patch is pretty simple and straight forward but it does impact the -help output of all tools using cl::opt. Specifically the options implemented in CommandLine.cpp (help, help-list, help-hidden, help-list-hidden, print-options, print-all-options, version) are all grouped together into an Option category, and these options are never hidden by the cl::HideUnrelatedOptions API.
Reviewers: dexonsmith, chandlerc, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7150
llvm-svn: 227093
Summary: cl::getRegisteredOptions really exposes some of the innards of how command line parsing is implemented. Exposing new APIs that allow us to disentangle client code from implementation details will allow us to make more extensive changes to command line parsing.
Reviewers: chandlerc, dexonsmith, beanz
Reviewed By: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7100
llvm-svn: 226729
No functional changes, I'm just going to be doing a lot of work in these files and it would be helpful if they had more current LLVM style.
llvm-svn: 225817
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.
This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...
llvm-svn: 222334
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
This patch contains the LLVM side of the fix of PR17239.
This bug that happens because the /link (clang-cl.exe argument) is
marked as "consume all remaining arguments". However, when inside a
response file, /link should only consume all remaining arguments inside
the response file where it is located, not the entire command line after
expansion.
My patch will change the semantics of the RemainingArgsClass kind to
always consume only until the end of the response file when the option
originally came from a response file. There are only two options in this
class: dash dash (--) and /link.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4899
Patch by Rafael Auler!
llvm-svn: 216280
This reverts commit r215784 / 3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa.
LLD has 3 StringSaver's, one of which takes a lock when saving the
string... Need to investigate more closely.
llvm-svn: 215790
This class is generally useful.
In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).
I've identified 2 other places in the
codebase that are open-coding this pattern:
memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)
I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.
Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.
llvm-svn: 215784
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.
This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.
llvm-svn: 211749
These errors are strictly unrecoverable and indicate serious issues such as
conflicting option names or an incorrectly linked LLVM distribution.
With this change, the errors actually get detected so tests don't pass
silently.
llvm-svn: 211260
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.
This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:
- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.
- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.
Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.
The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.
llvm-svn: 206822
This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.
llvm-svn: 203083
Tools that use the CommandLine library currently exit with an error
when invoked with -version or -help. This is unusual and non-standard,
so we'll fix them to exit successfully instead.
I don't expect that anyone relies on the current behaviour, so this
should be a fairly safe change.
llvm-svn: 202530
An intermediate solution until the problems with analyzer plugins linking with
llvm/Support and causing assertions due to duplicate GeneralCategory are solved.
llvm-svn: 200981
Summary:
The check performed in the comparator is invalid, as some STL
implementations enforce strict weak ordering by calling the comparator with the
same value. This check was also in a wrong place: the assertion would only fire
when -help was used. The new check is performed each time the category is
registered (we are not going to have thousands of them, so it's fine to do it in
O(N^2)).
Reviewers: jordan_rose
Reviewed By: jordan_rose
CC: cfe-commits, alexmc
Differential Revision: http://llvm-reviews.chandlerc.com/D2699
llvm-svn: 200853
This can still be overridden by explicitly setting a value requirement on the
alias option, but by default it should be the same.
PR18649
llvm-svn: 200407
Command line arguments that begin with @ but aren't a path to an
existing file currently cause later @file arguments to be ignored.
Correctly skip over these arguments instead of trying to read a
non-existent file 20 times and giving up.
Since the problem manifests in the clang driver, the test is in that
repository.
Fixes rdar://problem/15590906
llvm-svn: 196620
This fixes a logic bug pointed out by Juraj Ivancic.
No behavior change because none of the in-tree clients of
cl::ExpandResponseFiles check the return value. In this case, the
@prefixed arguments are left in the command line. Downstream command
line processing has the opportunity to emit errors about it, so this
isn't that bad.
llvm-svn: 196306
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file. The memory leaks in this version have been fixed. Thanks
Alexey for pointing them out.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 195064
This change is incorrect. If you delete virtual destructor of both a base class
and a subclass, then the following code:
Base *foo = new Child();
delete foo;
will not cause the destructor for members of Child class. As a result, I observe
plently of memory leaks. Notable examples I investigated are:
ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl.
llvm-svn: 194997
This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.
Differential Revision: http://llvm-reviews.chandlerc.com/D2068
Reviewed by Andy
llvm-svn: 194865
Before this patch we would strdup each argument. If one was a response file,
we would replace it with the response file contents, leaking the original
strdup result.
We now don't strdup the originals and let StringSaver free any memory it
allocated. This also saves a bit of malloc traffic when response files are
not used.
Leak found by the valgrind build bot.
llvm-svn: 187042
The plan is to use it for clang and lld.
Major behavior changes:
- We can now parse UTF-16 files that have a byte order mark.
- PR16209: Don't drop backslashes on the floor if they don't escape
anything.
The actual parsing loop was based on code from Clang's driver.cpp,
although it's been rewritten to track its state with control flow rather
than state variables.
Reviewers: hans
Differential Revision: http://llvm-reviews.chandlerc.com/D1170
llvm-svn: 186587
`typeinfo for llvm:🆑:GenericOptionValue').
Remove an "anchor" method for an abstract class. (This does not
increase the number of vtables.)
llvm-svn: 183830
Summary:
This patch allows using \n inside long help strings for command-line
options, so that all lines are equally indented. This is not a perfect solution,
as we don't (and probably don't want to) know about terminal width, but it
allows to format long help strings somehow readable without manually padding
them with spaces. A motivating example is -help output from clang-format (source
code in tools/clang-format/ClangFormat.cpp, see cl options offset, length,
style, and dump-config).
Reviewers: atrick, alexfh
Reviewed By: alexfh
CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D779
llvm-svn: 181608
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
(This time I believe I've checked all the -Wreturn-type warnings from GCC & added the couple of llvm_unreachables necessary to silence them. If I've missed any, I'll happily fix them as soon as I know about them)
llvm-svn: 148262
Get back getHostTriple.
For JIT compilation, use the host triple instead of the default
target: this fixes some JIT testcases that used to fail when the
compiler has been configured as a cross compiler.
llvm-svn: 147542
the Support library. Now its part of the TargetRegistry, and the three
commands that care about this explicitly register this extra bit of
version information.
The set of commands which care was computed by intersecting those which
use the Support library's version string printing and those that
initialize all the registered targets in a way that produces
a meaningful list. The only odd ball out is that 'clang -cc1as -version'
no longer prints the registered targets. I don't think anyone is really
interested in that (especially as the fact that llvm-mc does so is under
a FIXME), but if someone really does want this back I'll happily apply
the same patch there.
llvm-svn: 135757
function on the TargetRegistry. Also clean it up and use the modern LLVM
utility libraries available instead of rolling a few things manually.
llvm-svn: 135756
register extra version information to be printed. This is designed to
allow those tools which link in various targets to also print those
registered targets under --version.
Currently this printing logic is embedded into the Support library
directly; a huge layering violation. This is the first step to hoisting
it out into the tools without adding lots of duplicated code.
llvm-svn: 135755
comments claimed it did this, but the LHS value was actually an unused variable.
The new system considers only the '-foo' part when comparing it for typos
against flags that have values, but still look at the whole string for flags
that don't. That way, we'll still correct '-inst=combine' to '-instcombine'.
llvm-svn: 130685
developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.
Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.
llvm-svn: 128910
Also, have tools output -help-hidden rather than refer to --help-hidden,
for consistency, and likewise adjust documentation. This doesn't change
every mention of --help, only those which seemed clearly safe.
llvm-svn: 96578
Makes '--comma-separated val1,val2' mean the same thing as
'--comma-separated=val1,val2' (that is, 'val1' and 'val2' are not lumped
together as 'val1,val2'). Also declutters the main loop a bit.
llvm-svn: 89463
