| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously a "opt<std::optional<std::string>>>" would fail to
parse/would attempt to parse option value as argument.
|
|
This PR passes the VFS down to `llvm::cl` functions so that they don't
assume the real file system.
|
|
Reapplying now that buildbot has picked up the new configuration
that does not use -treat-scalable-fixed-error-as-warning.
-----
This removes the `LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS` cmake option
and the `-treat-scalable-fixed-error-as-warning` opt flag.
We stopped treating these as warnings by default a long time ago
(62f09d788f9fc540db12f3cfa2f98760071fca96), so I don't think it makes
sense to retain these options at this point. Accessing a scalable
TypeSize as fixed should always result in an error.
|
|
(#156336)"
This reverts commit 8f59a946740bf8dbe2574b33eaa431fde3ce9204.
Failed on clang-aarch64-sve-vls-2stage, which still uses the option.
|
|
This removes the `LLVM_ENABLE_STRICT_FIXED_SIZE_VECTORS` cmake option
and the `-treat-scalable-fixed-error-as-warning` opt flag.
We stopped treating these as warnings by default a long time ago
(62f09d788f9fc540db12f3cfa2f98760071fca96), so I don't think it makes
sense to retain these options at this point. Accessing a scalable
TypeSize as fixed should always result in an error.
|
|
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm::cl::opt` explicit
template instantiations for export with `LLVM_TEMPLATE_ABI` and
`LLVM_EXPORT_TEMPLATE`. This annotation currently has no meaningful
impact on the LLVM build; however, it is a prerequisite to support an
LLVM Windows DLL (shared library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
Annotating the `llvm::cl::opt` template instances for DLL export was not
straight-forward like other explicit template instances that have
already been annotated. Annotating them as documented
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst#templates)
results in link errors when building a Windows DLL using MSVC.
## Overview
There are two specific issues that appear when exporting the
`llvm::cl::opt` templates and compiling a Windows DLL with MSVC:
1. We cannot export `opt<std::string>`. This is because MSVC exports all
ancestor classes when exporting an instantiated template class. Since
one of `opt`'s ancestor classes is its type argument (via
`opt_storage`), it is an ancestor of `std::string`. Therefore, if we
export `opt<std::string>` from the LLVM DLL, MSVC forces
`std::basic_string` to also be exported. This leads to duplicate symbol
errors and generally seems like a bad idea. Compiling with `clang-cl`
does not exhibit this behavior.
2. The `opt` template instances other than `opt<bool>` get optimized out
because they are not referenced in the TU (`opt<bool>` actually is). It
is unclear exactly why MSVC optimizes these template instances away, but
`clang-cl` does not. Adding explicit references to the instantiated
`opt` template classes' vtables via implicit virtual destructor forces
MSVC to export them.
## Validation
Windows with MSVC
Windows with Clang
|
|
|
|
|
|
## Purpose
This patch is one in a series of code-mods that annotate LLVM’s public
interface for export. This patch annotates the `llvm/Support` library.
These annotations currently have no meaningful impact on the LLVM build;
however, they are a prerequisite to support an LLVM Windows DLL (shared
library) build.
## Background
This effort is tracked in #109483. Additional context is provided in
[this
discourse](https://discourse.llvm.org/t/psa-annotating-llvm-public-interface/85307),
and documentation for `LLVM_ABI` and related annotations is found in the
LLVM repo
[here](https://github.com/llvm/llvm-project/blob/main/llvm/docs/InterfaceExportAnnotations.rst).
The bulk of these changes were generated automatically using the
[Interface Definition Scanner (IDS)](https://github.com/compnerd/ids)
tool, followed formatting with `git clang-format`.
The following manual adjustments were also applied after running IDS on
Linux:
- Add `#include "llvm/Support/Compiler.h"` to files where it was not
auto-added by IDS due to no pre-existing block of include statements.
- Add `LLVM_ABI` to Windows-only code (auto generated with IDS on
Windows)
- Explicitly make classes non-copyable where needed to due IDS adding
`LLVM_ABI` at the class level
- Add `LLVM_TEMPLATE_ABI` and `LLVM_EXPORT_TEMPLATE` to exported
instantiated templates
- Add `LLVM_ABI_FRIEND` to a small number of `friend` function
declarations
- Add `LLVM_ABI` to a subset of private class methods and fields that
require export
- Add `LLVM_ABI` to a small number of symbols that require export but
are not declared in headers
- Add `LLVM_ABI` functions defined via X-macro
## Validation
Local builds and tests to validate cross-platform compatibility. This
included llvm, clang, and lldb on the following configurations:
- Windows with MSVC
- Windows with Clang
- Linux with GCC
- Linux with Clang
- Darwin with Clang
|
|
|
|
|
|
Create a helper template function to parse bool, to eliminate code
duplication.
|
|
|
|
The two variables using ManagedStatic that are exported by this
header are not actually used anywhere -- they are used through
SubCommand::getTopLevel() and SubCommand::getAll() instead.
Drop the extern declarations and the include.
|
|
Both sides here are known to be of StringRef.
|
|
It's useful to have some significant build options visible in the
version when investigating problems with a specific compiler artifact.
This makes it easy to see if assertions, expensive checks, sanitizers,
etc. are enabled when checking a compiler version.
Example config line output:
Build configuration: +unoptimized, +assertions, +asan, +ubsan
|
|
(#85879)
Reverts llvm/llvm-project#84990 because this causes a full rebuild after
the commit hash changes.
|
|
Include the `LLVM_REPOSITORY` and `LLVM_REVISION` in the version output
of tools using `cl::PrintVersionMessage()` such as dwarfdump and
dsymutil.
Before:
```
$ llvm-dwarfdump --version
LLVM (http://llvm.org/):
LLVM version 19.0.0git
Optimized build with assertions.
```
After:
```
$ llvm-dwarfdump --version
LLVM (http://llvm.org/):
LLVM version 19.0.0git (git@github.com:llvm/llvm-project.git 8467457afc61d70e881c9817ace26356ef757733)
Optimized build with assertions.
```
rdar://121526866
|
|
|
|
|
|
After #75679, it is no longer necessary to add the `All` pseudo
subcommand to the list of registered subcommands. The change causes the
list to contain only real subcommands, i.e. an unnamed top-level
subcommand and named ones. This simplifies the code a bit by removing
some checks for this special case.
This is a fixed version of #77041, where options of the 'All' subcommand
were not added to subcommands defined after them.
|
|
(#77041)"
This reverts commit fb7fe49960ae053c92985f3376d85a15bbd10d1a.
The commit introduced a bug where an option with the `All' subcommand
would not be added to a category initialized after that option.
|
|
After #75679, it is no longer necessary to add the `All` pseudo
subcommand to the list of registered subcommands. The change causes the
list to contain only real subcommands, i.e. an unnamed top-level
subcommand and named ones. This simplifies the code a bit by removing
some checks for this special case.
|
|
If a category has no options associated with it, the `--help-hidden`
command still shows that category with the annotation "This option
category has no options", and this is how it was implemented from the
beginning when the categories were introduced, see commit 0537a98878. A
feature to hide unrelated options was added later, in
https://reviews.llvm.org/D7100. Now, if a tool needs to hide unrelated
options that are associated with categories, leaving some of them empty,
those categories will still be visible on the `--help-hidden` output,
even if they have no use for the tool; see the changes in
`llvm/test/tools/llvm-debuginfo-analyzer/cmdline.test` for an example.
The patch ensures that only categories with options are shown on both
main and hidden help output.
|
|
This implements a post-commit suggestion for #75679.
|
|
The patch adds a helper method to iterate over all subcommands to which
an option belongs. Duplicate code is removed and replaced with calls to
this new method.
|
|
Buildbots reported:
.../CommandLine.cpp:1626:13: error: variable 'NearestHandler' set but not used [-Werror,-Wunused-but-set-variable]
|
|
The patch improves the reporting for the first option in the command
line when it looks like a subcommand name but does not match any
defined.
Before the patch:
```
> prog baz
prog: Unknown command line argument 'baz'. Try: 'prog --help'
```
With the patch:
```
> prog baz
prog: Unknown subcommand 'baz'. Try: 'prog --help'
prog: Did you mean 'bar'?
```
|
|
(#74557)
When a tool defines only one or two subcommands, the `[subcommand]` part
is not displayed in the `USAGE` help line. Note that a similar issue
for printing the list of the subcommands has been fixed in
https://reviews.llvm.org/D25463.
|
|
options for a custom subcommand (#71981)
Fixed build bot errors.
- Use `StackOption<std::string>` type for the top level option. This
way, a per test-case option is unregistered when destructor of
`StackOption` cleans up state for subsequent test cases.
- Repro the crash with no test sharding `/usr/bin/python3
/path/to/llvm-project/build/./bin/llvm-lit -vv --no-gtest-sharding -j128
/path/to/llvm-project/llvm/test/Unit`. The crash is gone with the fix
(same no-sharding repro)
**Original commit message:**
**Context:**
- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and
commit
https://github.com/llvm/llvm-project/commit/07670b3e984db32f291373fe12c392959f2aff67,
`cl::SubCommand` is introduced.
- Options that don't specify subcommand goes into a special 'top level'
subcommand.
**Motivating Use Case:**
- The motivating use case is to refactor `llvm-profdata` to use
`cl::SubCommand` to organize subcommands. See
https://github.com/llvm/llvm-project/pull/71328. A valid use case that's
not supported before this patch is shown below
```
// show-option{1,2} are associated with 'show' subcommand.
// top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp)
llvm-profdata show --show-option1 --show-option2 --top-level-option3
```
- Before this patch, option handler look-up will fail with the following
error message "Unknown command line argument --top-level-option3".
- After this patch, option handler look-up will look up in sub-command
options first, and use top-level subcommand as a fallback, so
'top-level-option3' is parsed correctly.
|
|
options for a custom subcommand (#71975)
…ooking options for a custom subcommand. (#71776)"
This reverts commit b88308b1b4813e55ce8f54ceff6e57736328fb58.
The build-bot is unhappy
(https://lab.llvm.org/buildbot/#/builders/186/builds/13096),
`GroupingAndPrefix` fails after `TopLevelOptInSubcommand` (the newly
added test).
Revert while I look into this (might be related with test sharding but
not sure)
```
[----------] 3 tests from CommandLineTest
[ RUN ] CommandLineTest.TokenizeWindowsCommandLine2
[ OK ] CommandLineTest.TokenizeWindowsCommandLine2 (0 ms)
[ RUN ] CommandLineTest.TopLevelOptInSubcommand
[ OK ] CommandLineTest.TopLevelOptInSubcommand (0 ms)
[ RUN ] CommandLineTest.GroupingAndPrefix
#0 0x00ba8118 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x594118)
#1 0x00ba5914 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x591914)
#2 0x00ba89c4 SignalHandler(int) (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5949c4)
#3 0xf7828530 __default_sa_restorer /build/glibc-9MGTF6/glibc-2.31/signal/../sysdeps/unix/sysv/linux/arm/sigrestorer.S:67:0
#4 0x00af91f0 (anonymous namespace)::CommandLineParser::ResetAllOptionOccurrences() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x4e51f0)
#5 0x00af8e1c llvm::cl::ResetCommandLineParser() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x4e4e1c)
#6 0x0077cda0 (anonymous namespace)::CommandLineTest_GroupingAndPrefix_Test::TestBody() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x168da0)
#7 0x00bc5adc testing::Test::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b1adc)
#8 0x00bc6cc0 testing::TestInfo::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b2cc0)
#9 0x00bc7880 testing::TestSuite::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5b3880)
#10 0x00bd7974 testing::internal::UnitTestImpl::RunAllTests() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5c3974)
#11 0x00bd6ebc testing::UnitTest::Run() (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x5c2ebc)
#12 0x00bb1058 main (/home/tcwg-buildbot/worker/clang-armv7-global-isel/stage1/unittests/Support/./SupportTests+0x59d058)
#13 0xf78185a4 __libc_start_main /build/glibc-9MGTF6/glibc-2.31/csu/libc-start.c:342:3
```
|
|
for a custom subcommand. (#71776)
**Context:**
- In https://lists.llvm.org/pipermail/llvm-dev/2016-June/101804.html and commit 07670b3e984db32f291373fe12c392959f2aff67, `cl::SubCommand` is introduced.
- Options that don't specify subcommand goes into a special 'top level' subcommand.
**Motivating Use Case:**
- The motivating use case is to refactor `llvm-profdata` to use `cl::SubCommand` to organize subcommands. See
https://github.com/llvm/llvm-project/pull/71328. A valid use case that's not supported before this patch is shown below
```
// show-option{1,2} are associated with 'show' subcommand.
// top-level-option3 is in top-level subcomand (e.g., `profile-isfs` in SampleProfReader.cpp)
llvm-profdata show --show-option1 --show-option2 --top-level-option3
```
- Before this patch, option handler look-up will fail with the following error message "Unknown command line argument --top-level-option3".
- After this patch, option handler look-up will look up in sub-command options first, and use top-level subcommand as a fallback, so 'top-level-option3' is parsed correctly.
|
|
This is a new attempt of https://reviews.llvm.org/D159481, this time as
GitHub PR.
`GenericOptionValue::compare()` should return `true` for a match.
- `OptionValueBase::compare()` always returns `false` and shouldn't
match anything.
- `OptionValueCopy::compare()` returns `false` if not `Valid` which
corresponds to no match.
Also adding some tests.
|
|
Differential Revision: https://reviews.llvm.org/D146104
|
|
|
|
This change is rather more invasive than intended. The main intention
here is to make CommandLine.cpp not rely on llvm/Support/Host.h. Right
now, this reliance is only in 3 superficial places:
- Choosing how to expand response files (in two places)
- Printing the default triple and current CPU in `--version` output.
The built in version system has a method for adding "extra version
printers", commonly used by several tools (such as llc) to report the
registered targets in the built version of LLVM. It was reasonably easy
to move the logic for printing the default triple and current CPU into
a similar function, and register it with any relevant binaries.
The incompatible change here is that now, even if
LLVM_VERSION_PRINTER_SHOW_HOST_TARGET_INFO is defined, most binaries
will no longer print out the default target triple and cpu when provided
with `--version`, for instance llvm-as and llvm-dis. This breakage is
intended, but the changes in this patch keep printing the default target
and detected in `llc` and `opt` as these were remarked as important
binaries in the LLVM install.
The change to expanding response files may also be controversial, but I
believe that these macros should correspond exactly to the host triple
introspection used before.
Differential Revision: https://reviews.llvm.org/D137837
|
|
These source files no longer use Optional<T>, so they do not need to
include Optional.h.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This applies to GetEnv and FindInEnvPath.
|
|
Users may partition parameters specified by configuration file and put
different groups into separate files. These files are inserted into the
main file using constructs `@file`. Relative file names in it are
resolved relative to the including configuration file and this is not
convenient in some cases. A configuration file, which resides in system
directory, may need to include a file with user-defined parameters and
still provide default definitions if such file is absent.
To solve such problems, the option `--config=` is allowed inside
configuration files. Like `@file` it results in insertion of
command-line arguments but the algorithm of file search is different and
allows overriding system definitions with user ones.
Differential Revision: https://reviews.llvm.org/D136354
|
|
As now errors in file operation are handled, check for file existence
must be done prior to check for recursion, otherwise reported errors are
misleading.
Differential Revision: https://reviews.llvm.org/D136090
|
|
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
|
|
This reverts commit 17eb198de934eced784e16ec15e020a574ba07e1.
Reverted for investigation, because ClangDriverTests failed on some builders.
|
|
Previously an error raised during an expansion of response files (including
configuration files) was ignored and only the fact of its presence was
reported to the user with generic error messages. This made it difficult to
analyze problems. For example, if a configuration file tried to read an
inexistent file, the error message said that 'configuration file cannot
be found', which is wrong and misleading.
This change enhances handling errors in the expansion so that users
could get more informative error messages.
Differential Revision: https://reviews.llvm.org/D136090
|
|
Class ExpansionContext encapsulates options for search and expansion of
response files, including configuration files. With this change the
directories which are searched for configuration files are also stored
in ExpansionContext.
Differential Revision: https://reviews.llvm.org/D135439
|
|
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
|
|
This reverts commit 6e491c48d6b9cadcc5b77f730dd83a1448197329.
There are missed changes in flang.
|
|
Functions that implement expansion of response and config files depend
on many options, which are passes as arguments. Extending the expansion
requires new options, it in turn causes changing calls in various places
making them even more bulky.
This change introduces a class ExpansionContext, which represents set of
options that control the expansion. Its methods implements expansion of
responce files including config files. It makes extending the expansion
easier.
No functional changes.
Differential Revision: https://reviews.llvm.org/D132379
|
|
Clang has support of virtual file system for the purpose of testing, but
treatment of config files did not use it. This change enables VFS in it
as well.
Differential Revision: https://reviews.llvm.org/D132867
|
|
This reverts commit 9424497e43aff088e014d65fd952ec557e28e6cf.
Some buildbots failed, reverted for investigation.
|
|
Clang has support of virtual file system for the purpose of testing, but
treatment of config files did not use it. This change enables VFS in it
as well.
Differential Revision: https://reviews.llvm.org/D132867
|
