Many command line option implementations, including getopt_long and our
Support/CommandLine.cpp, support `--` as an end-of-option indicator. All
the subsequent arguments are then treated as positional arguments.
D1387 added KIND_REMAINING_ARGS and 76ff1d915c9c42823a3f2b08ff936cf7a48933c5 dropped special handling of `--`.
Users need to add `def DASH_DASH : Option<["--"], "", KIND_REMAINING_ARGS>;` and
append `OPT_DASH_DASH` to the `OPT_INPUT` list., which is not ergonomic.
Restore this feature under an option and modify llvm-strings to utilize the
feature as an example. In the future, we probably should enable this feature by
default and exclude some tools that handle `DASH_DASH` differently (clang,
clang-scan-deps, etc. I suspect that many are workarounds for LLVMOption not
supporting `--` as a built-in feature).
Reviewed By: serge-sans-paille
Differential Revision: https://reviews.llvm.org/D152286
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view. I'm planning to deprecate
StringRef::{starts,ends}with_insensitive once the migration is
complete across the code base.
Differential Revision: https://reviews.llvm.org/D150426
When used to find an exact match, some extra context can be used to
totally cut some computations.
This saves 1% of the instruction count when pre processing sqlite3.c
through
valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null
Differential Revision: https://reviews.llvm.org/D142026
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
This reapplies 71d7fed3bc2ad6c22729d446526a59fcfd99bd03 which was
reverted by 3e2bd82f02c6cbbfb0544897c7645867f04b3a7e. This change
includes the fix for breaking the sanitizer bots.
As seen in https://bugs.llvm.org/show_bug.cgi?id=48880 the current
implementation for parsing grouped short options can return unclear
error messages. This change fixes the example given in the ticket in
which a flag is incorrectly given an argument. Also when parsing a
group we now keep reading past the first incorrect option and output
errors for all incorrect options in the group.
Differential Revision: https://reviews.llvm.org/D108770
As seen in https://bugs.llvm.org/show_bug.cgi?id=48880 the current
implementation for parsing grouped short options can return unclear
error messages. This change fixes the example given in the ticket in
which a flag is incorrectly given an argument. Also when parsing a
group we now keep reading past the first incorrect option and output
errors for all incorrect options in the group.
Differential Revision: https://reviews.llvm.org/D108770
Currently, `printHelp` behaves differently for options that:
* do not define `HelpText` (such options _are not printed_), and
* define its `HelpText` as `HelpText<"">` (such options _are printed_).
In practice, both approaches lead to no help text and `printHelp` should
treat them consistently. This patch addresses that by making
`printHelpt` check the length of the help text to be printed.
All affected tests have been updated accordingly. The option definitions
for llvm-cvtres have been updated with a short description or "Not
implemented" for options that are ignored by the tool.
Differential Revision: https://reviews.llvm.org/D107557
This is a mechanical change. This actually also renames the
similarly named methods in the SmallString class, however these
methods don't seem to be used outside of the llvm subproject, so
this doesn't break building of the rest of the monorepo.
In https://reviews.llvm.org/rG257b29715bb27b7d9f6c3c40c481b6a4af0b37e5,
the definition of OptTable::Info::Flags was changed from `unsigned
short` to `unsigned int`, but the definition/declaration of
OptTable::findByPrefix wasn't updated to reflect that.
This patch updates findByPrefix accordingly.
The method optionMatches() constructs 9865 std::string instances when comparing different
options. Many of these instances exceed the size of the internal storage and force memory
allocations. This patch adds an early exit check that eliminates most of the string allocations
while keeping the code simple.
Example inputs:
Prefix: /, Name: Fr
Prefix: -, Name: Fr
Prefix: -, Name: fsanitize-address-field-padding=
Prefix: -, Name: fsanitize-address-globals-dead-stripping
Prefix: -, Name: fsanitize-address-poison-custom-array-cookie
Prefix: -, Name: fsanitize-address-use-after-scope
Prefix: -, Name: fsanitize-address-use-odr-indicator
Prefix: -, Name: fsanitize-blacklist=
Differential Revision: D85538
for the advantage outlined by D83639 ([OptTable] Support grouped short options)
Some behavior changes:
* -i={0,false} is removed. Use --no-inlines instead.
* --demangle={0,false} is removed. Use --no-demangle instead
* -untag-addresses={0,false} is removed. Use --no-untag-addresses instead
Added a higher level API OptTable::parseArgs which handles optional
initial options populated from an environment variable, expands response
files recursively, and parses options.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D83530
POSIX.1-2017 12.2 Utility Syntax Guidelines, Guideline 5 says:
> One or more options without option-arguments, followed by at most one option that takes an option-argument, should be accepted when grouped behind one '-' delimiter.
i.e. -abc represents -a -b -c. The grouped short options are very common. Many
utilities extend the syntax by allowing (an option with an argument) following a
sequence of short options.
This patch adds the support to OptTable, similar to cl::Group for CommandLine
(D58711). llvm-symbolizer will use the feature (D83530). CommandLine is exotic
in some aspects. OptTable is preferred if the user wants to get rid of the
behaviors.
* `cl::opt<bool> i(...)` can be disabled via -i=false or -i=0, which is
different from conventional --no-i.
* Handling --foo & --no-foo requires a comparison of argument positions,
which is a bit clumsy in user code.
OptTable::parseOneArg (non-const reference InputArgList) is added along with
ParseOneArg (const ArgList &). The duplicate does not look great at first
glance. However, The implementation can be simpler if ArgList is mutable.
(ParseOneArg is used by clang-cl (FlagsToInclude/FlagsToExclude) and lld COFF
(case-insensitive). Adding grouped short options can make the function even more
complex.)
The implementation allows a long option following a group of short options. We
probably should refine the code to disallow this in the future. Allowing this
seems benign for now.
Reviewed By: grimar, jhenderson
Differential Revision: https://reviews.llvm.org/D83639
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.
If the user passes a flag like `-version` to a program, it's more likely
they mean `--version` than `-version:`, since there's no parameter
passed. Hence, give delimited arguments a penalty of 1 if the user input
doesn't contain the delimiter or no data after it.
The motivation is that with this, lld-link can suggest "--version"
instead of "-version:" for "-version" and "-nodefaultlib" instead of
"-nodefaultlib:" for "-nodefaultlibs".
Differential Revision: https://reviews.llvm.org/D61382
llvm-svn: 359701
Prior to this, OptTable::findNearest() thought that the input `--foo`
had an editing distance of 0 from an existing flag `--foo=`, which made
it suggest flags with delimiters more often than flags without one.
After this, it correctly assigns this case an editing distance of 1.
Differential Revision: https://reviews.llvm.org/D61373
llvm-svn: 359685
`Candidate` was a StringRef refering to a temporary string.
Instead, create a local variable for the string and use
a StringRef referring to that.
llvm-svn: 359604
